Connect the systems you already have when the core products still do their jobs and a narrow, maintainable link removes the real problem. Replace a product when its own workflow, data access or support has become the constraint. Start with one troublesome journey and compare the full cost of leaving it, connecting it and replacing it. A new platform can simply move an old problem into a more expensive place.
The question has become timely. In its business systems integration response published on 28 October 2026, the UK government describes both the gains from connected records and the barriers: cost, inconsistent interfaces, switching effort and ongoing maintenance. It drew on 63 written responses and 19 live sessions. That is useful evidence about the issues people raised, not a representative measure of how many UK firms have each problem.
I would not start by asking for an integration quote or an ERP demonstration. I would ask what happens between the first customer action and the final financial record, then find the point where the work breaks.
What is the failing job, exactly?
Pick one journey that matters to your business. It might be an accepted order becoming a job, a completed job becoming an invoice, or a returned item changing stock and the customer balance. Write the steps as they happen today, including the handoffs that rely on a spreadsheet, an email or someone’s memory.
For each step, record four things: who makes the decision, which system holds the authoritative record, what someone rekeys, and how an error is noticed. Use a few real, suitably protected examples. Include an awkward case such as a cancelled order, partial payment or changed customer address. The ordinary case often works in a sales demonstration; exceptions reveal the real cost.
Check whether the pain is inside one product or between products. If your job system cannot represent a partial completion, linking it to accounts will not fix that. If it records the job correctly but the invoice must be typed again, a connection may be enough. If a person is using a spreadsheet because nobody agreed who owns the price, neither route is ready until that rule is settled.
Our guide to CRM and accounting disagreements goes deeper on assigning ownership to shared records. Do that before asking two systems to synchronise everything in both directions.
Could your current supplier fix it without a new build?
Recheck the product you already pay for. Capabilities change. FreeAgent’s October product update describes broader integrations, bulk imports and more detailed controls for accountancy practices. That announcement does not prove its features fit your business, but it is a good reason to test the current version rather than rely on an assessment from a year ago.
Ask the supplier to show your exact task with test data. Does a built-in setting, import, export or supported marketplace connector cover it? What licence tier is required? Can your team correct a failed transaction? Who supports the connection when one side changes? The cheapest option on a price page may need an extra tier, a paid connector and regular manual checking.
If the built-in route handles the awkward cases, use it. A small configuration change is easier to support than a custom service with its own hosting, credentials and release cycle. Keep a written record of the settings and a named owner so the result does not disappear when a colleague leaves.
When is a connection the better option?
A connection is a good candidate when both products remain useful, expose supported ways to exchange the required data, and have clear responsibility for each field. You should be able to describe the rule in one sentence: “When a job is approved, create a draft invoice in accounts and report any rejected line to the finance owner.” That is a bounded piece of work with a visible result.
Start with a vendor-supported connector if it meets the need. If it cannot handle a business-specific rule, a focused integration may be justified. Keep the first version narrow. Transfer only the fields needed for the journey, log each transfer, retry safely after interruptions, and make failures visible to a person who can resolve them. A silent nightly sync that copies the wrong price is worse than a manual handoff that everyone can see.
The government response records that inconsistent data formats, interfaces and authentication approaches can make one-to-one links costly to build and maintain. It also notes that low-volume businesses may get too little benefit to justify the work. That is why I would estimate the volume and cost of the current manual task before commissioning a connection. If ten minutes of rekeying happens twice a month, a permanent integration may never earn back its maintenance cost. Those figures are a decision example, not a claim about any customer or a general payback rate.
For help planning a connection and its maintenance, see our system integration service.
When should you replace the product?
Replacement becomes more plausible when the product itself cannot run the essential job. Look for repeated workarounds around permissions, stock, pricing, approvals or reporting that the supplier cannot support. Also check whether the data you need can be exported in a usable form and whether the product is still maintained. A missing export or an unsupported version can make staying put increasingly expensive, even when the subscription looks modest.
Replacement is a larger programme than buying a licence. You must move data, train people, rebuild integrations, test historical access and decide what happens during the changeover. A new system can fit better and still cost more for several years. Bespoke software can make sense where a distinctive process genuinely needs it and the business is willing to own its maintenance. A mature SaaS product may be the sounder choice for common finance or payroll work. Some businesses will keep a standard system for regulated records and build only the operational layer around it.
Do not assume that a replacement removes every connection. Your new product may still need to talk to accounts, payments, the website or a customer’s system. Map those dependencies before comparing products. Our guide to choosing between overlapping SaaS tools covers the work and records that can be missed when a contract price is the only figure on the page.
How do you compare the three routes fairly?
Put keep and repair, connect, and replace on the same one-page worksheet. Use quotes and your own measured work where possible. Mark unknown prices as unknown and ask the supplier to fill them in. A neat spreadsheet with guessed savings is not a business case.
| Cost or test | Keep and repair | Connect | Replace |
|---|---|---|---|
| Initial work | Configuration, training and any data clean-up | Design, connector or build, testing and data mapping | Procurement, migration, configuration or build, training and cutover |
| Recurring cost | Current licences and manual checking | Existing licences plus connector, hosting, monitoring and support | New licences or hosting, support, upgrades and remaining integrations |
| Failure to test | Existing workaround continues | Records duplicate, arrive late or fail silently | History is missing, users cannot complete the job or old links fail |
| Owner after launch | Product owner and team lead | Business owner plus connector maintainer | Product owner, supplier or development partner, and support owner |
Calculate an annual running cost for each route: subscriptions and hosting, support, expected maintenance, and the measured time spent checking or correcting the journey. Add one-off change costs separately. Then compare over a period that covers the contract term and likely upgrade cycle. Do not turn hours into cash unless the work really can be redeployed or avoided; a faster process may improve service without reducing payroll.
Ask what happens if the supplier changes its price, API or support terms. Also ask who can export the data and how long that takes. These are ownership questions as much as technical ones. The government’s response identifies switching cost and vendor lock-in among the barriers raised by respondents; a decision that ignores the next exit will repeat the problem.
What should a small trial prove?
Run the preferred route against a short list of acceptance cases before signing off a full change. At minimum, test a normal transaction, a correction, a cancellation, a duplicate, a missing field and an interrupted connection. Confirm what appears in each system and which person sees a failure. If the work includes customer data, use appropriate test records and check permissions as well as the data mapping.
Give the trial a pass condition tied to the job, such as “the finance owner can find and correct every rejected invoice before the next billing run.” Avoid a vague promise that systems will be “seamless”. If a vendor cannot show the awkward case with your data shape, the risk has not gone away because the standard demo looks polished.
Where a replacement affects tax records, ask your accountant what must remain accessible. For example, HMRC’s guidance on changing Making Tax Digital for Income Tax software explains that past digital records still need to be kept securely and that a mid-year switch may require current-year records to be imported or recreated. That guidance is specific to MTD Income Tax. Apply the rules relevant to your own records and software, rather than assuming one retention period covers everything.
Who makes the final call?
The person accountable for the journey should choose with finance and the people who use the systems, informed by a technical review of the options. The choice is easier when you can show the failing step, the volume, the true running cost and a trial result. If the existing product can meet the need, keep it. If a supported connection fixes a narrow handoff, connect it. If the product cannot do the core job, plan a controlled replacement.
If you want help mapping one workflow and comparing those routes, talk to Ajairu about your software decision. Bring the current process and one awkward example; that is enough to start a useful conversation.