Zero-downtime migration · Assessment
Moving to a new system while the old one keeps running
For a migration that keeps getting postponed: a two-week written plan that includes the way back. A US marketplace moved from PHP to Node.js with zero outages.
FormatWritten assessment
Timeline2 weeks for the plan
PricingFixed-price assessment · hourly work
Proof3 case studies
The assessment in 4 parts
01 · Signs you need it
If two of these apply, this is a good fit.
- The migration has been postponed three times
- It’s planned for Saturday at three in the morning
- Nobody knows how you would go back
- The new system has been finished and waiting for months
- You are paying for both, and have been for longer than planned
02 · What you get
What the plan sets out:
- The order in which parts of the system move, and the one thing that stays unchanged while they do. Usually that is an interface, a schema or an address.
- The way back, written as a procedure someone can follow at three in the morning without making a single decision.
- Which parts run in both systems at once, for how long, and how the two are kept in sync during that time.
- The measurement that says the old system can be switched off, instead of a date somebody picked in a meeting.
03 · How we decide
STEP 01Keep one thing unchanged.On a US marketplace we kept the MySQL database in place while the language, framework, hosting and mobile apps all changed. That gave us a fixed point for checking that the new version behaved like the old one.
STEP 02Sync in both directions.A record created in the new system appears in the old one, and the reverse, for as long as both are in use.
STEP 03The way back must not depend on what you’re changing.If going back relies on the part you are replacing, a failure in that part blocks the way back too.
STEP 04The old system goes when its last user has left.Analytics show who still uses it. With mobile apps that can take a while, because people update when they choose, and switching off the old backend would break the version still installed on their phones.
04 · If we find nothing
Sometimes the work shows that the migration isn’t needed at all. The document then sets out the reasons.
Proof
Where we’ve done this before
Case study 04 · MarketplaceZero outagesA US marketplace moved from PHP to Node.js with zero outages. Its two databases were synced in both directions for more than a year, and going back was a change of origin at the CDN that took seconds.Read the case study →Case study 09 · Identity1 working dayA national identity system moved off its old registry gradually, pulling from it every month while both stayed live.Read the case study →Case study 13 · Data15 min → 0.2 sA reporting warehouse rebuilt underneath a BI tool whose queries and schema had to stay exactly as they were. The report for the largest customer now opens in two tenths of a second, down from more than fifteen minutes, and every customer’s saved reports kept working.Read the case study →
FAQ
Questions about this service
Read access to the code and the schema of both systems, and someone who knows why the old one behaves the way it does. The two weeks start once we have that access. The plan doesn’t require production data.
Yes, as a separate engagement. We agree on it after the plan, because only then do we know how long the two systems will have to run side by side.
Until the data shows the old one is no longer used. On the longest migration we have run, that took more than a year.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.