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.
Get in touchWhy 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.
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.
Implementation and knowledge transfer
We agree the scope before implementation starts. Booking a separate assessment is not a prerequisite.
Agree the scope
Clarify goals, the technical context and responsibilities together.
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.
Technical resources
Technical articles · Workshops
Optional tools and formats
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.
Talk about your project
Let us discuss what support fits your project.