Cloud Modernization
We decide with you what gets rebuilt — and then rebuild it wave by wave.
Consulting and delivery for teams whose systems are older than the demands on them: the architecture decision, the migration plan, and the rebuild carried out while the business keeps running.
Rebuild or rewrite is decided against your code and your operations, not against a reference architecture. And we say so when the cheapest route is to leave a system exactly as it is.
SEE THE ASSESSMENTWhy modernization gets postponed
Modernization rarely fails on the technology. It fails on a decision nobody wants to make: what gets rebuilt, in which order, and what stays as it is for now.
While that decision stays open, the risk grows on both sides. The existing system gets more expensive to run, and the planned replacement gets bigger, because by now it is meant to do everything.
What usually follows is a rewrite alongside the day job — and a state where two systems are maintained and neither one is ever switched off.
How you know it is time
Six triggers teams come to us with. The more of them fit, the less another target-picture discussion will do for you.
- A small change to one feature drags tests and sign-offs through half the system.
- Operations depend on runtimes or database versions that no longer receive security updates.
- Infrastructure cost keeps climbing and nobody can attribute it to an application or a product.
- A data-centre contract, a licence or a reporting obligation has set a date that is not negotiable.
- New requirements around integration, load or data handling no longer fit the existing structure.
- Nobody goes near one part of the system because the person who built it has left the company.
Rewrite or incremental rebuild
We do not start from a target architecture. We start from the question of which route interrupts the business least, and the answer is more often a rebuild in place than a replacement.
Incremental modernization — the normal case
The existing behaviour stays in production while individual parts are replaced. The work can stop after any wave, and each wave delivers something on its own.
A rewrite — the exception
A replacement pays off when the domain is being rewritten anyway, the old system can no longer be extended, and there is a date on which it gets switched off. Without all three, the rewrite costs more than the rebuild.
Change nothing — also a result
Some systems run steadily, change rarely and cost little to keep. Modernizing them is the wrong investment, and that is what the analysis will say.
Microservices are an outcome, not a premise
Splitting into separate services pays off when several teams have to release independently of each other. Where one team owns the system, a well-bounded monolith is the cheaper answer.
Which route is right depends on the state of the system and on how your organization is cut. We put the options side by side with effort, risk and running cost, and recommend one — the decision stays with you.
What we take on
Seven pieces of work that belong together in a modernization. Which of them you need depends on where you start; we say which ones we consider unnecessary before the proposal.
The architecture decision
We assess the boundaries, dependencies and data model of the existing system and write down what each option costs and risks — with a recommendation, not with a list.
Migration planning
Which data, interfaces and user groups move when, what has to run in parallel while they do, and what the way back out of each wave looks like.
Delivery sequencing
The order follows risk and benefit: first the thing that relieves operations or lets something be switched off — not the most interesting piece of engineering.
Platform requirements
What the target environment has to provide for the rebuild to hold: runtime, data handling, network boundaries, delivery path and observability. Only then can the vendor question be answered.
Risk reduction before the first move
Before anything moves, a net goes underneath it: automated tests on the business-critical paths, reproducible environments, and a deployment that can be rolled back.
Business continuity
Live operations come first. Cut-overs run through parallel operation, feature switches and planned windows, and every step has a way back that was rehearsed beforehand.
Your team's capability
We work in your repositories and through your reviews. At the end your team knows the new parts because it built them with us, not because it sat through training.
What exists at the end
What you keep when the engagement ends, regardless of how far the rebuild has got by then:
- An architecture decision record in the repository, with the options that were rejected and the reason each one was.
- A migration plan with waves, dependencies, acceptance criteria and stop points.
- A risk register: what can go wrong during the rebuild, what it would mean for operations, and what was built in against it.
- Automated tests on the business-critical paths, running in your pipeline.
- Runbooks for cut-over and roll-back — rehearsed, not only written.
- A list of what was deliberately not modernized, with the reasoning and a date for the next review.
These outputs live in your repository and your wiki, not in a folder on our side. They are still worth something if you finish the rebuild with somebody else.
How an engagement runs
Four steps, in this order. You can stop after the first one and still keep a basis for the decision that you can work from.
Assessment
Fixed scope, fixed result: we read the code, the operations and the delivery path ourselves and put the options side by side with effort and risk.
The decision
You decide which route is taken. We say beforehand which one we consider wrong, and we put the reasoning in writing.
First wave
The first step reaches production before the second one is planned. Every change goes through a pull request somebody on your team reads.
Handover
Operational handover, documentation, and the rest of the plan in a form your team carries on with without us.
Engagement models
Four ways into the work. Which one fits is decided in the assessment or the fit check; the pages behind them state scope, duration and price in full.
Analyse first
When it is still open what the rebuild would cost and return: a fixed-scope analysis that ends in a prioritised roadmap.
The delivery path first
When the application is not the constraint but the route into production is: pipelines, environments and operations first, rebuild afterwards.
Build the target environment
When the destination is settled but the environment to run it on does not exist yet — with a fixed start and end date.
A rebuild across several waves
Several months with a fixed number of days per week, where the rebuild runs alongside the day job. Scope and term are set case by case.
What you can check
There is no figure from a client engagement on this page. Earlier modernizations were not measured in a way that would prove anything here, and we do not extrapolate to fill the space.
A number belongs here: how long a wave took, running cost before and after, error rate during parallel operation. There is no reliable one. As soon as a client releases a measurement, it goes here — not before.
References
What we have worked on, described without metrics, because we never collected any.
Delivery model
Who does the work, who reviews it, and where delivery accountability stays.
Articles
How we think about modernization, migration and architecture decisions — public, and at full length.
Relevant case studies
Case studies for this work, with context, intervention and handover. Each one appears only once the client has released it in writing.
No case study for this work is published yet. The first one is being written and is waiting on the client's release.
What is not included
Modernization does not stop where the proposal does. These five requests are the ones we turn down — better before the decision than halfway into the second wave.
Round-the-clock operations, on-call cover and SLA-backed run responsibility
We build platforms and hand them over ready to run. Running them is a different business — a managed-service provider can commit to that, we cannot.
Projects with no in-house engineering team
Knowledge transfer is part of every engagement. With no team to hand over to it turns into permanent outsourcing — a model we do not offer.
Transformation programmes with many parallel workstreams
Past roughly four concurrent streams you need a delivery organization. We work in a small setup; anything else would mean buying in people we do not know.
A fixed price for a whole transformation, quoted before anyone has looked
Pricing an unexamined legacy estate is guesswork. We estimate after a short assessment — and we will say so when the rebuild is not worth it.
ERP module consulting, customizing and ABAP development
Cloud-native engineering around an existing ERP estate is our work. Inside the module itself you want people who do nothing else all day.
Questions we get about modernization
Do we have to move to microservices for this?
No. Splitting into services pays off when several teams have to release independently. Where that is not the case, we recommend a tidied-up monolith and write down why.
Can the rebuild run alongside the day job?
Yes, and in practice there is rarely another way. That is why each wave is cut so that it can reach production on its own and has a rehearsed way back.
What happens if we have to stop halfway through?
The system keeps running. We modernize so that every wave ends in an operable state — never in a half-step that only works once the next one lands.
We want to move to the cloud. Is lifting the virtual machines enough?
When a data-centre contract is running out, a lift can be the right first step. As a destination it rarely is: it moves cost around and changes nothing about how hard the system is to change.
Who decides the target architecture?
You do. We supply the options with effort, risk and running cost, plus a reasoned recommendation. The decision and its reasoning are documented and stay readable afterwards.
Do we need an engineering team of our own?
Yes. Whoever changes the system afterwards has to have been there during the rebuild, or a second system appears that nobody in-house knows. Without that team it becomes permanent outsourcing.
Do you modernize systems that are not going to the cloud?
Yes. Much of the work — boundaries, tests, delivery path, handover — is independent of where the system runs. Where a data centre is the better choice, you hear that before the proposal.
Is the rebuild worth it?
The assessment answers that with a fixed scope: options, effort, risk, and a recommendation you are free to turn down.