Stop Waiting for Legacy Systems: How the Strangler Pattern Fixes Real Integration Problems

A global manufacturer came to my team with a problem that kills thousands of businesses every day. Their web store made synchronous calls to SAP for every order. Each transaction took 12 seconds. Customers abandoned their carts. Revenue dropped.

The business wanted fast online ordering, but they couldn't risk replacing SAP. Twenty years of business logic lived in that system. The IT team kept trying to make SAP faster, but SAP wasn't built for real-time web traffic.

We solved this with the strangler pattern, but not how most people think about it. The hardest part wasn't writing code. It was changing how the team thought about SAP.

Why Teams Build Legacy Prisons

Most teams approach legacy integration with a simple question: "How do we connect everything to SAP?" This seems logical. SAP holds the truth about inventory, pricing, and business rules. Of course, the web store should ask SAP before accepting an order.

I see this pattern everywhere. Teams do it with Oracle ERP, Salesforce, and even modern monoliths. There's nothing wrong with these systems. SAP is great at managing complex business processes. Oracle handles data well. The problem comes when you try to make them do everything.

This thinking creates what I call legacy prisons. Every new feature requires SAP changes. Every performance problem becomes a SAP problem. Development speed drops to SAP's pace.

I've seen teams spend months building caching layers, trying to make SAP respond faster. They add load balancers, connection pools, and circuit breakers. These help, but they miss the real issue.

The web store doesn't need to wait for SAP. It needs to send data to SAP.

The Mental Shift That Changes Everything

Stop making SAP the controller. Make it a destination.

In the old model, this happens:

1. Customer clicks "Place Order"
2. Web store calls SAP
3. Customer waits 12 seconds
4. SAP responds
5. Web store shows confirmation

In the new model:

1. Customer clicks "Place Order"
2. Web store accepts order immediately
3. Web store shows confirmation
4. System sends order to SAP later

SAP still processes the order. Business rules still apply. But the customer experience goes from painful to instant.

This needs a shift in thinking. Teams stop asking "How fast can we make SAP?" and start asking "How fast can we accept orders?"

Implementation with the Strangler Pattern

The strangler pattern makes this transition safe. You don't replace SAP overnight. You move functionality away from real-time SAP calls.

I built a demo that shows exactly how this works: event-driven-orders on GitHub. The code uses Go for the backend services and Next.js for the dashboard, but the concepts work with any technology stack.

Phase 1: Accept Orders Fast

Start by building a simple order acceptance service. This service validates basic information and stores orders in a fast database. The web store calls this service instead of SAP directly.

// From the demo - accept orders without waiting for SAP
func (h *Handler) CreateOrder(w http.ResponseWriter, r *http.Request) {
    var order models.Order
    if err := json.NewDecoder(r.Body).Decode(&order); err != nil {
        h.respondWithError(w, http.StatusBadRequest, "Invalid request body")
        return
    }

    if order.ID == "" {
        order.ID = uuid.New().String()
    }
    if order.CreatedAt.IsZero() {
        order.CreatedAt = time.Now()
    }
    if order.Status == "" {
        order.Status = "pending"
    }

    // Write to order service only - SAP gets events via Kafka
    orderServiceResp, err := h.orderServiceClient.CreateOrder(&order)
    if err != nil {
        h.respondWithError(w, http.StatusInternalServerError, "Failed to process order")
        return
    }

    // Return immediately - customer doesn't wait for SAP
    h.respondWithJSON(w, http.StatusCreated, orderServiceResp)
}

The order service handles what the web store needs: fast responses and immediate confirmation. SAP integration becomes a background job.

Phase 2: Async SAP Integration

Build a separate service that sends orders to SAP. This service reads from your fast database and makes SAP calls without blocking the web store.

The demo shows how to handle this with events. When the order service saves an order, it publishes an event. The SAP integration service processes these events at its own pace.

Phase 3: Move Logic Gradually

This is where the strangler pattern shines. You can move business logic from SAP to your new services one piece at a time.

Start with simple validations. If SAP checks that customer IDs exist, build that check into your order service. If SAP validates product availability, add that logic to a product service.

Each piece you move makes your system faster and more independent. SAP becomes less central to daily operations.

Patterns That Make This Work

The strangler pattern doesn't work alone. You need other patterns to handle legacy integration.

Anti-Corruption Layer

SAP's data structures likely don't match your business needs. Build a translation layer between your new services and SAP. This keeps SAP's design problems from spreading to your new code.

My demo doesn't include this layer to keep things simple, but you'll want one in production. It turns clean order objects into whatever format SAP expects.

Circuit Breaker

SAP will go down. It will get slow. Don't let this break your web store.

Build circuit breakers around SAP calls. When SAP fails, stop calling it for a while. The event broker handles queuing and retries. Your customers continue to receive prompt responses, even when SAP experiences issues.

Handling the Hard Parts

Every team asks the same questions about this approach. Let me address the big ones.

What About Data Consistency?

Orders can fail in SAP after you've accepted them. Build logic to handle this. The demo includes examples of order status tracking and customer notifications.

Here's the thing: perfect consistency isn't needed. Customers care more about fast responses than perfect real-time inventory counts. You can solve edge cases with good customer service.

What About Business Rules?

SAP contains complex business logic built over decades. You don't need to copy all of it right away.

Start by identifying which rules must run in real-time versus which can run later. Customer validation might need to be real-time. Complex pricing calculations might not.

Build new rules outside SAP when possible. This gives you more control and faster development cycles.

What About Rollbacks?

This is where event-driven design shines. You don't build compensation workflows. You replay events.

Every order change becomes an event in your broker. If something breaks, replay the events to rebuild the correct state. If SAP goes down for hours, replay all the missed events when it comes back up.

The event stream becomes your source of truth. SAP problems become replay problems, which are much easier to solve.

The Business Impact You Actually Care About

Most strangler pattern articles focus on technical benefits, such as reduced coupling and improved performance. Those matter, but they miss the bigger picture.

The real win is development speed.

When teams stop building everything around SAP, they can add features faster. They can test changes without touching SAP. They can deploy updates without needing to coordinate with SAP administrators.

At Microsoft, I worked with customers who cut feature delivery time from months to weeks using this approach. They didn't just improve performance. They changed how fast the business could respond to market changes.

One Fortune 500 client reduced their order processing time from 12 seconds to under 1 second. But more importantly, they went from shipping new features quarterly to shipping weekly. Their development speed increased 10x.

Making This Change in Your Organization

The technical implementation is straightforward. The team change is harder.

Start with one small win. Pick a single API call that's causing pain and build an async alternative. Show the performance improvement. Let teams see the difference.

Don't try to convince people with presentations. Show them working code.

Build the async order example from the demo. Run both versions side by side. Let managers click buttons and see the difference. Fast responses change minds faster than diagrams.

Getting Team Buy-In

Teams resist this approach because it feels risky. They've learned to trust SAP as the source of truth. Moving away from real-time SAP calls feels like losing control.

Address this by starting with low-risk workflows. Order confirmations are perfect for this. Customers expect email confirmations anyway, so async processing feels natural.

Avoid high-stakes workflows at first. Don't start with financial transactions or compliance-critical processes. Build confidence with simple wins first.

Managing Technical Debt

This approach does create complexity. You're running multiple systems instead of one. You need to monitor more services and handle more failure modes.

But this complexity pays for itself quickly. Teams move faster when they're not limited by SAP's constraints. The increased development speed outweighs the operations overhead.

Plan for this complexity from the start. Build good monitoring and alerting. Invest in automation. Treat operations as necessary, not an afterthought.

Your Next Steps

The strangler pattern works because it changes how teams think about legacy systems. Instead of building around legacy constraints, you build around business needs.

Start by examining the demo code at github.com/jgardner04/strangler-demo. Run it locally and see how the async flow works. The Next.js dashboard shows order status in real-time, even though SAP processing happens in the background.

Then identify one synchronous call in your system that's causing pain. Build an async alternative. Measure the difference. Show your team the results.

The goal isn't to eliminate SAP. It's to stop letting SAP control your development speed.

What synchronous legacy calls are slowing down your team? What would happen if you stopped waiting for them?

I'd like to hear about your challenges with migration. Drop me a line and let's discuss how the strangler pattern might work for your specific situation.