The person who knows it is leaving soon
Do the extraction and documentation now and the replacement afterwards. Losing them mid-project is the single worst outcome available and we have seen it happen.
Migration · Sage
Sage 50, 100, and 300 are long-established products running a substantial number of American businesses on installations that in some cases predate the people maintaining them. Leaving one is closer to a legacy system replacement than to a cloud migration, and it should be planned that way.
Tell us the version, how it is hosted, and who understands it. That last answer shapes the sequencing.
Stay if
Timing matters more here than for any other migration on this site, because the knowledge required lives with people rather than in documentation.
Do the extraction and documentation now and the replacement afterwards. Losing them mid-project is the single worst outcome available and we have seen it happen.
Sage 100 and 300 have real operational capability. If you use it, we are not a replacement and Acumatica or NetSuite are the products to look at.
Do not migrate systems immediately before a sale or a raise. Acquirers prefer clean, boring history in a system they recognise, and mid-migration books are neither.
Real reasons
Several of these products are maintained rather than developed. Where the roadmap has effectively ended, staying is a decision with an expiry date attached.
On-premise Sage installations are difficult to integrate with, which becomes the binding constraint as the rest of your stack moves to systems that expect APIs.
A machine in a cupboard, a backup regime somebody owns, and a version upgrade nobody wants to attempt. That ongoing cost is real and rarely counted.
The standard failure sequence on these projects is to design the target, build it, then discover in month four that the source data cannot be extracted at the grain the design assumed. Everything after that is renegotiation. Our first phase is extraction and nothing else — can we get everything out, repeatedly, with a check that proves it is complete. It feels slower and it is the reason these projects land.
The distinction matters. A cloud-to-cloud migration is a data exercise with a known API on both ends. An on-premise Sage exit involves database reads against an undocumented schema, business rules encoded nowhere in writing, and a person whose knowledge is the actual documentation.
We run these through our legacy replacement methodology rather than our standard migration process, and the difference is real: extraction proven first, undocumented behaviour discovered by comparing outputs, and parallel running until the new system has agreed for two full cycles.
A system running that long has accumulated behaviour that exists in no document. A customer with a bespoke discount hard-coded a decade ago. A calculation that rounds differently from the documented method and has been quietly correct because everything downstream expects it. A transaction type that skips a check for reasons nobody remembers.
These are found by running historical inputs through the new logic and investigating every difference. Each one resolves into either a bug in the new system or an undocumented rule in the old one, and both outcomes occur.
Sage 50 and 100 typically mean direct database access against the application schema. Sage 300 has more API surface but on-premise installs frequently do not expose it. Sage Intacct is a different product entirely and has its own guide.
We establish the path during a short paid discovery before quoting anything, because promising a fixed price before reading the schema is how these engagements go over.
Switching off a Sage installation usually means losing the ability to query anything not migrated. That becomes a problem three years later when a dispute, an audit, or an acquirer asks about a pre-cutover transaction.
Everything gets extracted into an accessible, documented archive whether or not it is operationally needed. Storage is cheap; reconstructing an archive from a decommissioned server is not.
Questions
Designing the target before the source is proven is how these projects become renegotiations.