Migrating a Legacy ERP Without Downtime

The client's ERP system had been running since before most of our engineers had finished school. Twenty two years of institutional data, custom reports nobody remembered commissioning, and a warehouse floor that depended on it staying online during every single shift. A traditional cutover, where you take the old system down on a Friday night and bring the new one up by Monday, was never on the table. The floor does not stop for a migration weekend.

Running two systems in parallel, on purpose

Instead of a single cutover, we built a synchronization layer that let the legacy system and the new platform run side by side for eleven weeks. Every transaction wrote to both. Every report was generated from both and diffed automatically, and any mismatch paged an engineer within minutes rather than surfacing as a quarterly reconciliation headache.

This was slower and more expensive to build than a straight migration script. It was also the only version of this project that let the client's operations team keep trusting the numbers on their screen every single day of the transition, instead of taking a leap of faith on cutover night.

The cutover was the boring part

By the time we were confident enough to make the new system authoritative, the actual switch was almost anticlimactic. We flipped write traffic to the new platform during a low volume window, kept the legacy system in read only shadow mode for two more weeks as a safety net, and then retired it without a single warehouse shift losing a minute of throughput.

The migration succeeded because the boring, unglamorous parallel running phase did the hard work months before cutover night.

Twenty two years of data moved. Zero minutes of downtime. The warehouse floor never had a reason to notice anything had changed, which is exactly the point.