Rewrite a legacy system or migrate it by domain?
A twenty-year-old system still runs the operation. Do you throw it away and rebuild, or take it apart one piece at a time?
The full rewrite is seductive because it promises to leave everything behind at once. The problem is that it concentrates risk in a single moment: the day of the switch. Until that day the new system has never seen a real user, and on that day it sees all of them at once.
There is also a less visible problem. A twenty-year-old system contains rules nobody remembers writing, and that somebody uses. Rewriting it from a specification means rewriting only the rules someone was able to tell you about.
The decision
Migrate by domain. You identify the areas of the system, bookings, sites, corporate clients, their dependencies and the order in which they can be separated. Then the new system takes one responsibility at a time, with the old one still carrying the rest. Every step has a clear boundary and a way back.
The price is a long coexistence: for a while data lives in two places and you need a layer keeping them aligned. It is a real cost, and it must be told to the client at the start. In exchange you get to verify each part under real conditions, with real users, and to stop at any moment without having broken anything.
When you do rewrite
When the system is small enough to be verified in full before the switch, or when it has no users depending on continuity. And when the new one can run in shadow alongside the old, receiving the same traffic and comparing answers, before taking the wheel.
In every other case the right question is how much a day of downtime costs. If the answer is a lot, you migrate by domain.
Describe the system. We'll tell you what we see.
Ten minutes, one question at a time. At the end, our honest read of the case. It's the filter, before the call.