0% completed
Key Insights and Implications
On This Page
The Organizational Side
The pattern is simple to describe and harder to run. Here is what decides whether a migration finishes.
1. The routing layer. The facade, also called the proxy or the router, is the core of the pattern. It sends each request to either the old system or the new one, so it has to stay available. Its rules are usually based on one of three things:
- Feature flags: a setting that turns a piece of new behavior on or off.
- User segmentation: sending some users to the new service first.
- API versioning: routing on a version header or a path.
2. Data while both systems run. This is the hardest part of the pattern. Both systems may be writing to the same data, and both have to see correct values. The usual options are:
- One shared database: both systems use the same database, so there is nothing to keep in step. The price is that the new service inherits the old schema.
- One-way replication: the legacy store stays the source of truth, and its changes are copied to the new store. The new side only reads at first.
- Event sync: every write publishes an event, and each side keeps its own store. This is the most work and it gives the most independence.
3. Monitoring and feedback. The new system has to match or beat the old one on speed, reliability and behavior. You cannot tell without measuring both.
- Log and monitor both systems, with the same metrics on each.
- Collect feedback from the users whose traffic has moved.
4. The cost of running two systems. Two systems mean two sets of infrastructure, two deployments to manage, and two codebases where a defect can appear. That cost is real, so the goal is always to retire the old system rather than to run both indefinitely.
5. Untangling the old system. Legacy code is often tightly coupled, which means one part cannot be changed or removed without changing others. Some refactoring is usually needed before the first piece can be separated.
6. Shared state. State is any data the system holds between requests, such as a session or a cart.
- Shared state: both systems read and write one cache or store, so they always agree.
- Separate state: each system keeps its own, and the two are synchronized. Conflict-free replicated data types (CRDTs) are one way to merge them without conflicts.
7. Communication between services. As new services appear, they have to talk to each other and to the legacy system.
- Event sourcing: store every change as an event and rebuild the current state by replaying those events. Both systems can then read the same record of changes.
- Message brokers: a separate service such as RabbitMQ or Kafka that carries messages between them.
8. A way back. Decide how to reverse a migration before you need to. Feature flags or routing rules let you send traffic back to the legacy system without a deployment.
9. Testing.
- Contract testing: check that the new service behaves the way its callers expect.
- End to end testing: check the old and new systems working together, not just each alone.
- Performance testing: load test the new service and compare the numbers against the old one.
10. Migrating without downtime. Users should not notice the move. Blue-green deployment and canary releases both help. Blue-green deployment runs two identical environments. Traffic switches from the old one to the new one in one step, and back again if the new one misbehaves. A canary release sends a small share of traffic to the new version, which you watch before widening it.
11. Changing the data model. If the new system stores data differently, the data has to be transformed on the way across. Tools such as Kafka Connect can stream between databases and transform records as they move.
12. Security. Each new service is a new thing to attack. Keep the usual controls in place: rate limits at the gateway, authentication between services, and regular scanning for known vulnerabilities.
The Organizational Side
Cross-functional teams. A migration needs people who know the legacy system and people who know the new stack. If they are in separate teams, every piece of work needs a handover between the two.
Talk to the people affected. Operations staff and end users often notice problems before the metrics show them. Keep a channel open to them for the length of the migration.
Write down what you learn. The first two or three pieces teach you most of what the rest will cost. Record it, because the migration outlasts the people who started it.
Reading Progress
0%
On This Page
The Organizational Side