Sage integrations

Most business systems we take over talk to Sage somewhere. Sales invoices post to the ledger overnight. Customers created in the system appear in Sage. A stock adjustment in Sage comes back the other way. The integration was written once, years ago, against the Sage version of the day, by the person who wrote the rest of the system, and it has been working since. Finance depends on it every morning.

That's why it holds everything else still. The link uses Sage Data Objects or an ODBC connection nobody has documented. It runs on one machine, because Sage 50 keeps its data in files on a Windows machine or server and the integration has to be there or on the same network. It breaks whenever Sage is upgraded, because the SDO version has to match the installed Sage 50 exactly, and then someone has to remember how it was installed. Moving the system to the web, or to a new server, or to a developer who isn't the original one, means touching the Sage link, and nobody wants to.

It depends on which Sage you're on, because the routes differ by product.

Sage 50 is the one that shapes a modernisation. A system moving to the web can't talk to Sage 50 from the cloud on its own; it needs a small agent on the Sage side, or the postings go through Sage's import files, or the integration becomes the reason to look at Sage 200 or Sage Accounting. All three are legitimate. The assessment says which fits.

1. Map every crossing. Which records go in which direction, when, what triggers them, and what happens when Sage is closed, locked or being backed up. The assessment produces this from the code and from watching a day's run.
2. Reproduce it in a test company. A restored Sage backup in a separate company, a copy of the system's database, and the existing integration run against both, so we have a known-good result to compare with.
3. Rebuild the link on the supported route. SDO done properly for Sage 50, with the version dependency isolated in one place; REST for Sage 200 or Sage Accounting.
4. Run old and new side by side against the test company, and reconcile: every posting, every customer, every balance, matched.
5. Switch, with the old link kept and switchable back until finance has closed a period on the new one.

The mapping from step one is the document that survives everything after it, including a later move to a different Sage product.

To Sage 200, Sage Accounting, Intacct or Xero. The integration is rebuilt against a different API and the field mapping is redone, because the products don't share a data model. The plan is the same as above with one more rule: never move Sage and the system in the same period. Move the system with the Sage 50 link kept working, close a period, then move Sage with the system already stable, or the other way round. Doing both at once leaves finance with nothing to reconcile against.

Sage is the ledger, so nothing posts to live Sage until the same postings have been reconciled in a test company. Every change to the integration is tested against a restored Sage backup and a copy of the system's data, then run in staging with the postings matched line by line, before it connects to live. The old link stays switchable back until a period has been closed on the new one.

Yes, and it's usually one crossing at a time. Invoices first, because that's the one finance watches; customers and suppliers next; stock or payments last. Each runs side by side and reconciles before the next moves, and the whole exercise can pause between stages with everything still working.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Sage integration it maps every crossing, confirms which Sage product and version you're on and which route it supports, and prices the rebuild as a fixed number, on its own or as a stage of a wider modernisation. What drives the price and the payment terms each have a page.

Sage 50 gets a new version every year, and v34 is current. Each one has to be matched by the SDO the integration uses, so each upgrade is a chance for the postings to stop. Sage 50 has been a 64-bit application since v30, while the integration route stays 32-bit, which catches out anyone rebuilding the machine it runs on. And the person who knows how the link was installed is a single point of failure for the month-end.

Map it, reproduce it in a test company, rebuild it on the supported route, reconcile before switching. Marc Allington has built and maintained Sage integrations inside the VB, Access and .NET systems he's taken over, and builds on modern .NET now. Everything we build runs in your own accounts, with full source code and ownership transferring to you on final payment.