The spreadsheet everyone depends on
One workbook holds the real schedule. It lives on one machine, breaks when two people open it and nobody is sure which version is current.
CRM · ACCOUNTS · JOB SYSTEMS · DATA
Enter it once. Get it where it needs to go.
A quote in one system should not mean another evening updating the rest. We connect the tools you already use and plan migrations when it is time to move, checking what each system can support before you commit.
01 · What breaks first
The work happens twice. Sometimes three times.
Re-keying between systems
A job is booked in one system, invoiced in another and reported in a third. Someone retypes it each time, and the mistakes surface at the worst moment.
A platform nobody wants to touch
The old platform still works, just about. The supplier has moved on, the person who understood it has left and every replacement quote comes back frightening.
02 · What we build
Connect what works. Retire what does not.
01
A survey of what actually connects
We list every system, who owns it, what data moves between them and which of those moves is currently a person with a keyboard.
WHAT CONNECTS 02Working connections between your tools
CRM, finance, calendars and job systems joined through their APIs so a booking, a quote or a payment appears everywhere it should without anyone retyping it.
API JOINS 03Data mapped and cleaned before it moves
Field-by-field mapping, duplicates resolved, dead records marked, formats fixed. Where two records disagree we ask which source wins rather than guessing. Dates, phone numbers and postcodes are normalised to one format before the receiving system ever sees them.
CLEAN RECORDS 04A staged cutover with a way back
Old and new run together while we verify counts and totals. A written rollback plan, tested before the switch, not drafted on the night.
SAFE SWITCH 05Spreadsheet bridges retired properly
The workbook holding the business together is replaced by something with permissions, history and a backup, and it stops depending on one person remembering how it works.
WORKBOOK RETIRED
03 · How we work on this
We read the data first. Then we scope it.
Integration work starts with reading your data, not with choosing a tool. We look at real records, not the schema someone drew three years ago, because the exceptions are where migrations fail. Then we tell you which connections are straightforward, which are awkward because of how the systems were built and which are not worth doing at all.
You keep the accounts, the licences and the data. Credentials stay yours, API keys are issued from your own accounts rather than ours and mappings are documented in plain English rather than buried in a script only we can read. Where a vendor's API cannot do what you have been told it can, we say so early, in writing, rather than discovering it during cutover week.
04 · How it is delivered
Nothing moves live. Until it has moved safely once.
What you hand over to start
We are given read-only access and one named person per system who can answer questions about the odd records. Exports come out of every system in scope so we can count what is really there before anyone fixes a date: records, duplicates, blanks and the cases nobody mentioned.
Mapping sheet and sign-off
Every field gets a destination, a transformation rule or a deliberate decision to drop it. You approve that sheet before any build starts and it stays the reference we work to when somebody asks later why a field is empty.
Dry run and reconciliation
We migrate into a sandbox and reconcile totals, counts and a sample of records against the live system. When the numbers do not balance we trace the records causing it and run the whole load again rather than signing off a variance. Failures surface here, on a copy, while the live system is still the one you are working in.
Cutover, watch, then decommission
We run the switch ourselves at a quiet hour agreed with you, with rollback ready and your named contact reachable in case a call has to be made. We watch the first days of real use, fix what surfaces and only then turn the old system off.
05 · Questions before the scope
Before you start. Practical questions, answered.
What to consider when deciding whether this work is right for your business.
Can Sage 200 and our HubSpot pipeline share one customer record without double entry?
Usually. Sage 200 publishes a scheduled export we can read, and the two sides are joined on a single customer key that one system owns and the other follows. The thing to settle before any of it is which system is allowed to create a customer, because both creating is where duplicates come from.
Our purchase orders get typed into SQL Server and then again into Sage 50. Why?
Usually because nothing owns the order number. When one system issues it and everything else stores it as a reference on the same record, the second entry becomes a lookup rather than a retype. Until then both systems believe they hold the original, and neither can be corrected safely.
Our web form should create a lead in the CRM, but some never appear. Findable?
Yes. A failed handoff normally leaves nothing behind, which is exactly why nobody notices, so each message is written to a queue before delivery and stays there until the CRM confirms it has been stored. What failed becomes visible and can be replayed rather than reconstructed from memory.
Customers ring us for copies of statements that only exist in Sage. Any way round it?
Often the route is the ledger's own export. Sage produces the statement as a file on a schedule, and that file feeds a page the customer signs into, so nobody rekeys a balance and nobody emails a spreadsheet. The ledger stays the master and the page only reads from it. Customer portals and checkouts
We still run an old Microsoft Access database. Would you rip it out first?
Probably not. Access is often doing something narrow and doing it correctly, so use the product you already pay for while a read-only copy of its tables is published where other systems can reach it. Once they read that copy instead of the file share, replacing it becomes a choice rather than a cliff edge. When a tool replaces it
Our records have to stay in the UK. Does that rule out moving to cloud hosting?
No. The region is set when the database is created and cannot be changed afterwards without another migration, so it is decided before anything moves rather than discovered later. The same check applies to backups, which is where data quietly leaves the country while everybody is watching the main system.
WORKING EXAMPLESWebsites built for businesses we own and run
WRITTEN SCOPEDeliverables and price agreed before work begins
DIRECT CONTACTA named person responsible for your project
CLEAR HANDOVERAccounts, access, documentation and support agreed up front
06 · Where this lands
Where this lands hardest. Old systems, strict records.
FOR INSURANCE BROKERS AND MGAS
Less rekeying
Explore document handling, enquiry workflows and connections between policy, CRM and finance systems.
EXPLORE → FOR SOLICITORS AND LAW FIRMSGive your people more time
Reduce repeated requests, scattered updates and manual copying between systems.
EXPLORE → FOR PRIVATE HEALTHCARE AND CARE PROVIDERSMake the admin easier
Clearer websites and booking journeys help people find the right service.
EXPLORE →A migration is not done when the data lands. It is done when nobody opens the old system to check.
NEXT · Tell us what you want to improve
Start with the change you want to make.
Tell us which systems need to connect and what information should move between them. We will check the available routes before proposing a build.