Get the business off paper without stopping it.

You will recognise some of this

• The real system of record is a spreadsheet on one person’s machine
• Orders arrive on WhatsApp and are copied into a book
• Stock is counted on paper and typed up days later
• Your software runs on a PC in the back office that nobody is allowed to switch off
• The vendor who built it has gone quiet, or wants a rewrite fee
• Nobody can answer "what did we sell yesterday" before lunch

Why not just rewrite it?

Because the old system encodes a decade of decisions nobody wrote down, and a clean-room rewrite discovers them one production incident at a time. We migrate incrementally: the new system takes over one capability at a time while the old one keeps running, so there is always a working business and always a way back.

What about the data?

It is usually the hardest part and the part most plans underestimate. We treat migration as software: versioned, reversible, tested against a copy of production, and verified by reconciliation rather than by hope. We do this continuously for our own multi-tenant platform, which is where the discipline comes from.

How disruptive is the cutover?

Designed to be boring. By the time we switch, the new system has been running alongside the old one against real data, and the rollback path has been tested rather than merely documented.

How it runs

1. 1

   Audit what actually exists

   One to two weeks

   Including the parts that are not written down: the workarounds, the side spreadsheets, and the one report the owner actually trusts. That report is usually the real specification.

2. 2

   Migrate one capability at a time

   In steps, not a big bang

   The new system takes over a single job while the old one keeps running. There is always a working business and always a way back. A clean-room rewrite discovers a decade of undocumented decisions one incident at a time; we would rather not.

3. 3

   Reconcile the data

   Every step

   Migrations are versioned, reversible, tested against a copy of production, and checked by reconciliation against your existing numbers — not by asking you to trust the import. We do this continuously for our own tenant fleet.

4. 4

   Cut over and train

   When the numbers already agree

   Parallel running first, then a switch that should feel like a non-event, then training for the people who have to use it on a busy Saturday.

When not to hire us for this

• A big-bang replacement over a weekend — we will decline it rather than do it badly
• Digitizing a process that should simply be stopped; sometimes the answer is fewer steps, not software
• Businesses that want the old screens rebuilt exactly, bug for bug
• Anything where the data cannot be reconciled against a source we can both check

Questions

Our system is a desktop app from 2014. Is that too old?

No. That is a common starting point, and often a good one — a desktop app usually has a clear data model underneath it, which makes the migration more predictable than an undocumented web system.

Can you work with our current developer?

Yes, and it usually goes better when we do. Whoever knows the old system is the most valuable person in the room.