Service by service migration
Each capability carved out of the monolith and stood up on its own, so the system kept earning while it changed shape underneath.
Loading…
Loading…
Manufacturing
A Gulf manufacturer
When this Gulf manufacturer first called us, the software running their operations was already ten years old. It had grown one feature at a time into a single large application that did everything at once, from order intake to production scheduling to reporting. Nobody on the current team had written the original code, and the few people who understood its older corners had long since moved on. It still worked, which is exactly why nobody had touched the foundation in years. But it had quietly become the thing the whole business was afraid to break.
The cost of keeping it alive was creeping up too. The application could only run as one big piece, so it lived on one big always on server sized for the busiest hour of the busiest day. For most of the month that capacity sat idle and the invoice arrived anyway. Hosting was expensive, scaling meant buying a bigger box, and there was no easy way to give one busy part of the system more room without paying for all of it.
| Before | After | |
|---|---|---|
| Release process | Batched, late night, all hands | Routine, working hours, several a week |
| Hosting cost | One oversized always on server | Right sized services, down 40 percent |
| Downtime risk | Every deploy could darken the factory | Zero downtime, fall back ready at all times |
| Architecture | Single monolith doing everything | Independent services behind a gateway |
The deeper problem was not the cost. It was that the team had stopped being able to change anything quickly. Because everything shipped together, every release was an all hands event. A small fix to a report meant redeploying the entire system, and any mistake could take production offline for a factory that runs around the clock. So releases were rare, batched up, and dreaded. People planned them for late evenings, kept rollback notes handy, and held their breath. A platform that everyone is scared to deploy is a platform that slowly stops moving, and that is where this one had landed.
A full rewrite was the obvious temptation and the obvious trap. A big bang replacement would have meant freezing the business for months and betting everything on a single switchover, with no safety net if it went wrong. The manufacturer could not afford the freeze, and frankly neither could we in good conscience recommend it. We needed a way to modernize the system while it stayed online and kept earning, one piece at a time.
We used a strangler fig migration, named after the vine that grows around a tree and gradually takes its place. Rather than replace the monolith in one move, we carved capabilities out of it one at a time, stood each one up as its own service, and quietly routed traffic to the new version once it was proven. The old system kept running the whole time. Every step was small, reversible, and shippable on its own, which is what made the whole thing safe.
Each capability carved out of the monolith and stood up on its own, so the system kept earning while it changed shape underneath.
A single front door that could send each capability to the old code or the new service, switchable in moments and reversible just as fast.
Automated tests and one button deploys turned shipping from a midnight event into a quiet part of the working day.
Every service described in code and right sized to its real demand, so capacity matched the work instead of the worst case.
Metrics, logs, and traces added to each service as it shipped, giving the team a clear view of behavior end to end.
The legacy path stayed ready throughout, so any surprise meant a calm switch back rather than an outage.
Zero downtime cutover
Because the API gateway could route each capability to either the old or the new code, we never had a single moment where the system went dark. We moved traffic gradually, watched the new service behave under real load, and kept the legacy path ready to fall back to. The factory kept running through every step of the migration.
The moment the team still talks about came early, with the first capability we moved across. Out of long habit they had booked it for a late evening and lined up the usual rollback notes, half expecting a long night. We flipped a slice of real traffic to the new service at around four in the afternoon, watched the dashboards settle, and then watched a little longer because it felt too quiet. Nothing broke. One of the engineers said it felt strange to ship something and just go home. That first calm release was the moment everyone stopped bracing, and the rhythm of the place started to change.
By the time the last meaningful capability had moved across, the platform felt like a different one to work with. Infrastructure cost was down 40 percent, because right sized services scaled with real demand instead of one oversized server idling through the quiet hours. Deploy frequency was four times higher, since a change to one service no longer dragged the whole system along with it. Most importantly, releases stopped being something to fear. The team went from a handful of nervous deployments a year to shipping in normal working hours, several times a week.
| Before | After | |
|---|---|---|
| Release cadence | A handful a year | Several a week |
| Scaling | Buy a bigger box | Each service scales on its own |
| A small fix | Redeploy the whole system | Ship one service in minutes |
| Team mood on deploy day | Held breath and rollback notes | An ordinary afternoon task |
lower infra cost
more deploys
downtime at cutover
faster releases
They rebuilt the platform underneath us and we never once had to take it offline. We used to plan releases for midnight and hope. Now we ship on a Tuesday afternoon and barely think about it.— IT Director, a Gulf manufacturer
FAQ
We use the strangler fig pattern. New services are carved out of the monolith one capability at a time, and an API gateway routes traffic to either the old code or the new service. The legacy system keeps running until each piece is proven and switched over, so there is never an all or nothing cutover and you can always fall back.
The old monolith ran as one application on one large always on host sized for peak load, so most of that capacity sat idle and was paid for anyway. Splitting it into right sized services that scale independently meant each one used only what it needed, and describing the infrastructure as code let us tune capacity to real demand instead of the worst case.
Nothing moved all at once. The API gateway let us shift one capability at a time, send a slice of real traffic to the new service, watch it under load, and keep the legacy path ready as a fallback. Because every step was small and reversible, the production systems stayed online from the first day to the last.
Book a free consultation with our engineers.