Four Ways to Migrate to Event Sourcing

"We can't do Event Sourcing. We're not starting from scratch." This is one of the most common objections I hear when consulting teams on Event Sourcing. And it's understandable. Most teams don't have the luxury of a greenfield project. They have existing systems, legacy code, and ongoing business requirements. The idea of introducing Event Sourcing into that reality feels impossible.

But here's the truth: most successful Event Sourcing adoptions happen in existing systems, not greenfield projects. The question is not whether you can migrate, but how. There are multiple strategies, each with different trade-offs. The right choice depends on your context, your constraints, and your goals.

In this post, I'll walk you through four migration strategies we have seen in practice. Not theoretical approaches, but real patterns from real projects. Some succeeded, some were painful, and one was abandoned entirely. That honesty is important, because migration is not just a technical challenge. It's also an organizational one.

Strategy 1: Big Bang

The Big Bang approach means replacing the entire system (or a major part of it) at once. Old system off, new system on. Or, more realistically: old system frozen, new system built in parallel.

When it makes sense:

• The old system is stable and can keep running during development
• There is little pressure for new features on the old system
• A complete rewrite is already being considered
• The team has experience with Event Sourcing

When it doesn't:

• The old system requires ongoing development
• The team is still learning Event Sourcing
• There is no runway for a multi-year transition
• External integrations can't wait for the new system

A real example: One of our customers had a 30-year-old codebase. It was not cloud-ready, not scalable, and had known bottlenecks. But the system was stable. It generated revenue through support contracts with existing customers, and there was little demand for new features. They decided to freeze the old system and build a new, future-proof system in parallel.

This is normally a dangerous decision. You're betting everything on the new system. But in this case, it was right. It took a few years, but it worked. Today, they are glad they made that choice.

The key insight: Big Bang can work when the old system is stable enough to sustain itself while you build the new one. The risk is lower when you're not racing against a failing system. If your legacy system is actively falling apart, Big Bang is probably not your strategy.

Best practices:

• Only choose Big Bang when the old system can keep running without major investment
• Have a solid rollback plan
• Accept that it will take years, not months

Strategy 2: Strangler Fig

The Strangler Fig approach (named after the strangler fig tree that grows around its host) means building new features with Event Sourcing while old features remain in the existing system. Over time, the new system "strangles" the old one, gradually taking over functionality until the old system can be decommissioned.

When it makes sense:

• The old system requires ongoing development (you can't freeze it)
• You want to minimize risk (at least on paper)
• The team is still learning Event Sourcing
• You have time for a gradual transition

When it doesn't:

• The old codebase is a tangled monolith with unclear boundaries
• You need to migrate quickly
• The cost of maintaining two systems is prohibitive

A real example: One of our customers had a legacy system that required ongoing development. Freezing it was not an option, so they chose the Strangler approach. It was painful. The old code was a monolith, extremely tangled. Extracting pieces without breaking countless cross-dependencies was slow and expensive. It worked in the end, but it cost them a lot of money and took years.

An honest assessment: In retrospect, a parallel rebuild (Big Bang) might have been faster and cheaper. But Big Bang is harder to sell to management. Strangler Fig feels "safer" because you're not betting everything on a new system. Sometimes that feeling of safety costs more than it saves.

Best practices:

• Start with a clearly bounded new feature, not a migration of existing functionality
• Be realistic about the state of the old code
• Consider honestly whether Big Bang might actually be better

Strategy 3: Event Sourcing as Add-on

The Add-on approach means keeping the CRUD system as the source of truth while writing events additionally, as a side effect. Read models are built from these events for purposes like audit trails, analytics, or compliance reporting. The write side stays CRUD; only the read side becomes event-driven.

When it makes sense:

• Regulatory requirements demand an audit trail
• You need better analytics without changing the core system
• Everyone agrees that CRUD keeps the authority
• The team wants to learn Event Sourcing with low risk

When it doesn't:

• There is disagreement about which system should be authoritative
• The organization has competing factions with different goals
• You actually need Event Sourcing on the write side

A real example: We have seen this approach attempted once. It was ultimately abandoned, and the reason was not technical. It was organizational.

Running two systems in parallel immediately raised the question: Who has authority? Which system is the source of truth? How do you resolve conflicts when they disagree?

This became a textbook example of Conway's Law. There were two factions in the company: one wanted to keep CRUD, the other wanted to move to events. Neither side was willing to give up control. After months of discussions and meetings, they decided to abandon the initiative entirely.

The sad part: The problems that originally motivated them to evaluate Event Sourcing? They still have them today, years later. But you have to be willing to move.

Best practices:

• Only use this approach when there is clear, uncontested agreement on authority
• Treat it as a stepping stone, not an end state
• Be honest with yourself: if the organization can't agree on who owns the truth, this approach will fail

Strategy 4: Bounded Context First

The Bounded Context First approach means identifying one bounded context that would benefit from Event Sourcing, migrating that context completely, and leaving the rest of the system in CRUD. You can repeat this for other contexts later, or not, depending on whether it makes sense.

When it makes sense:

• The existing system already has a service-based architecture
• New functionality needs to be added that can be isolated
• Integration between services is already API-based
• The team can focus on one area at a time

When it doesn't:

• The existing system is a monolith without clear boundaries
• Services share databases or have tight coupling
• There is no natural isolation point

A real example: A customer needed to add new functionality that could be cleanly isolated. Instead of bolting it onto the existing system, they decided to build it as a separate service using Event Sourcing. Since the existing system was already service-based and all communication happened through APIs, the internal implementation of the new service was irrelevant to the rest of the system.

The scope was manageable. It was done in a few weeks.

Why it worked: The existing architecture made isolation easy. They didn't have to untangle a monolith. They just added a new service that happened to be event-sourced. The rest of the system didn't even know.

Best practices:

• Start with new functionality rather than migrating existing features
• Prefer systems that already have service boundaries
• Keep integration simple: APIs, no shared databases

Choosing the Right Strategy

There is no universally correct strategy. The right choice depends on your specific situation. Here are some questions to guide your decision:

How stable is your old system? If it can sustain itself without major investment, Big Bang becomes viable. If it requires ongoing development, consider Strangler Fig or Bounded Context First.

How experienced is your team? If Event Sourcing is new to the team, Bounded Context First gives you a safe space to learn without risking the entire system.

What does your architecture look like? If you already have services communicating via APIs, Bounded Context First is straightforward. If you have a tangled monolith, extraction will be painful regardless of strategy.

Can your organization agree on authority? If there are competing factions, Add-on will fail. You need alignment before you start.

How much risk can you accept? Big Bang is high risk, high reward. Strangler Fig feels safer but can be more expensive. Bounded Context First is low risk if you have clean boundaries.

A rough guide:

• Big Bang: Old system is stable, team is experienced, you have years of runway
• Strangler Fig: Active development required, team learning, want to minimize perceived risk
• Add-on: Regulatory needs, clear agreement on CRUD authority, stepping stone only
• Bounded Context First: Service architecture exists, new isolated functionality needed

Common Pitfalls Across All Strategies

Regardless of which strategy you choose, watch out for these common mistakes:

Underestimating data migration. Your historical data needs to be converted to events, or at least made accessible to the new system. This is often more work than expected.

Ignoring integrations. External systems expect your current APIs. Changing your internal architecture doesn't magically change their expectations.

Trying to be perfect. Start simple. You can iterate. The first version doesn't need to be the final architecture.

Forgetting the team. Migration is not just a technical challenge. Your team needs to learn new concepts, new tools, new ways of thinking. Budget time for that.

Underestimating organizational resistance. As the Add-on example showed, technology is often the easy part. Getting people aligned is harder.

Just Start

There is no perfect strategy. The best strategy is the one you can actually execute given your constraints.

Start small. Pick the approach that fits your situation. Learn from it. Adapt.

Be honest. About the state of your code. About the capabilities of your team. About the politics of your organization.

Move. The projects that failed were not the ones that chose the wrong strategy. They were the ones that never started.

Event Sourcing in a legacy system is not just possible. It's common. Most of the systems we work with are not greenfield. They are existing systems with real history, real constraints, and real value that needs to be preserved.

The question is not whether you can migrate. The question is which path you'll take.

If you're evaluating how to introduce Event Sourcing into your existing system, we're happy to help. Reach out at hello@thenativeweb.io or explore the Introduction to Event Sourcing to learn the fundamentals.