💡 Target Audience: Senior Backend Engineers and Tech Leads who are highly anxious about potential service outages or data loss during infrastructure migration.

No matter how great a new infrastructure is, the fear of "What if the service crashes during DB migration?" keeps many companies trapped in expensive legacy platforms.

However, for real-time communication services, you do not need to migrate 100% of your historical data to the new DB on day one. Below is the Strangler Fig pattern applied to real-time communication — a migration playbook with no cutover night, plus the failure modes it does *not* protect you from.

Step 1: Routing New Traffic

There is no need for mandatory app updates or sudden server maintenance. You simply add a basic routing rule at your API Gateway.

Starting today, every newly created chat room or video call session is routed directly to the HyperBabel API. You will immediately see a drop in traffic costs from the legacy end.

Step 2: Graceful Decay of Old Data

What about the previously active chat rooms? Leave them on the legacy platform.

Users will continue interacting in their existing chat rooms without noticing any difference. Over time, active participation in old rooms naturally drops, and they become archived/inactive with zero live traffic.

Step 3: Archiving and Shutting Down Legacy

After a parallel operation period of 1 to 3 months, live traffic on the legacy platform converges to near zero. At this phase, you can safely run a batch script to export the remaining historical "chat text data" to your own cold storage, and finally shut off the legacy API completely.

Why the pattern works: traffic is skewed, history is not

The reason this works is a property of conversation, not of any particular platform. Live throughput concentrates in recently created rooms, while old rooms decay into archives that are read occasionally and written almost never.

That means routing *only new rooms* moves most of your live cost early, while the expensive-to-migrate part — years of history — can move slowly, or never move at all.

The rollback question, answered before you need it

A migration plan without a rollback trigger is a hope, not a plan. Define these before you route the first room:

• Trigger: new-path error rate above your normal baseline for more than N minutes, or delivery latency regression beyond an agreed threshold.
• Action: flip the routing rule back. Because only *new* rooms were routed, rollback affects the smallest possible population and no historical data has moved.
• Blast radius: one routing rule. This is the entire reason the pattern is safe — the rollback is a config change, not a data restore.

Keep the old SDK shipping in your client for at least one release cycle so a rollback does not require an app-store review.

Five failure modes this pattern does *not* prevent

Honesty is more useful than reassurance:

1. Split search. Users searching "all my messages" now query two systems. Either federate the search or accept a date boundary in the UI — decide deliberately, do not discover it in a support ticket.
2. Identity drift. If user IDs are minted differently on each platform, cross-platform features (mentions, blocks, moderation) break subtly. Unify identity *before* routing traffic.
3. Notification duplication. Two platforms can both decide to push. Route push through one system only, from day one.
4. Webhook gaps. Analytics and billing pipelines silently miss the new path unless you move webhooks first. This is the most common quiet failure.
5. Never finishing. Parallel operation is comfortable, and "we'll decommission next quarter" can last two years. Put the shutdown date in the plan and defend it.

When *not* to use this pattern

• Small datasets. If your entire history fits in a single export, a one-shot migration over a maintenance window is simpler and finishes sooner.
• Strict compliance boundaries that forbid the same user's data existing in two systems simultaneously.
• Feature parity gaps. If the new platform lacks something the old rooms depend on, routing new rooms hides the gap until the worst moment.

The 30-second version

Route new rooms, leave old rooms alone, move webhooks first, and define the rollback trigger before the first flip. The pattern's value is not that it is clever — it is that the rollback is one config change and no data has moved yet.