Migrating without a big bang

Replacing an old application in one go sounds tidy and almost always goes wrong. A phased migration is slower on paper and faster in practice.

  • Migratie
  • Architectuur
  • .NET

Why the big bang stalls

In a full rebuild the roadmap stands still for as long as it takes. Meanwhile the old application stays in use and therefore keeps changing. Every change has to be made twice, and the date slips.

On top of that, the knowledge about the old application is usually implicit. Only when a user misses something does it turn out there was a rule that had never been written down.

The strangler approach

Put a reverse proxy in front of the old application and move functionality to the new stack module by module. Every finished module goes live; the rest simply keeps running.

One thing matters here: write characterisation tests on the flow you are moving first. Those tests describe what the system does today — including the behaviour nobody can explain any more — and that is exactly what you want to preserve.

What you pick up along the way

  • Automate deployment before you start; manual rollouts become untenable with two systems.
  • Put database migrations in the pipeline, with a worked-out rollback.
  • Keep a single source of truth for authentication, so users do not sign in twice.
  • Measure from day one: without numbers you cannot show the new module is better.

Running into the same thing?

Email the question. You get an answer from whoever wrote the article.

An unexpected error occurred. Reload 🗙