Cloud migration & modern software architecture: the decision guide

Most cloud migrations do not fail in the cloud. They fail because of an architectural decision that nobody made consciously.

This sounds exaggerated, but it is the pattern behind the expensive projects: A company moves its application "to the cloud" because the data centre is being phased out or the board has issued a cloud target. The software remains the same, only now it runs on rented hardware instead of the company's own. Six months later, the bill is higher than before, the application is no faster and nobody can say what has actually improved.

Cloud migration and software architecture are not two separate issues, but the same decision from two perspectives. The question is never just "Where do we move it to?", but always "In what form?". This guide takes you through both: the paths to the cloud, the basic architectural question behind it and the pragmatic path that is right for most SMEs.

Cloud migration is an architectural decision, not an infrastructure task

The first reflex when it comes to cloud migration is the wrong one: treat it as a move. Dismantle servers, rebuild them somewhere else, move cables. In fact, success is determined by a question that has little to do with servers: how much of the existing structure you take with you and how much you reorganise along the way.

This is precisely where the established cloud migration grid, which Amazon Web Services has made known as the "7 R's", comes in. These are seven basic ways to move an application to the cloud, and they differ not in terms of technology, but in the degree of change to the architecture:

In short: The further down this table, the more architecture work and the more potential benefit. Rehost is the fastest way and delivers the least. Refactor is the most expensive and delivers the most, if the application is worth it.

The most common mistake in the midmarket is to move everything via Rehost and wait for the cloud effect that never comes. An application that is designed to run on a single large server will not suddenly become elastic in the cloud. It only becomes more expensive because you are now paying for availability that you had previously written off. Replatforming is the better default for most people: managed database, managed container, less operation without having to touch half the code base. And you can save Refactor for the one or two systems that really support your business.

Monolith, microservices or modular monolith: the fundamental architectural question

Once "Refactor" is on the table, the real question of software architecture arises: how do you tailor the application? And this is where a misconception has persisted for years that has burnt through more SME budgets than any cloud provider: that "modern" is synonymous with "microservices".

There are essentially three architectural patterns to choose from.

The monolith is an application that is built, tested and delivered as a single piece. For a long time, this was synonymous with "legacy". Wrongly so. For most applications, a well-cut monolith is the fastest and cheapest way to build and operate software.

Microservices break down the same application into many small, independently deliverable services that talk to each other over the network. This gives large organisations with many teams working in parallel independence and comes at the price of a distributed system that is much more difficult to operate, monitor and debug.

The modular monolith is the pragmatic middle ground that is currently gaining acceptance: an application that runs externally as a deployable piece, but is cut internally into clearly delineated modules with clean boundaries. You get the organisation of microservices without the operating costs of a distributed system.

An example makes the difference tangible. Take a B2B shop with the areas of catalogue, pricing, checkout and invoicing. As microservices, these would be four separately deployable services with four databases that communicate via the network: maximum independence, maximum operating costs. As a modular monolith, there are four modules in one application, each with a clear boundary and its own internal interface, but delivered together. If pricing really needs its own scaling later on because it is under load, it can be detached as a separate service precisely at this prepared boundary. You only pay for the complexity when you need it, not as a precaution on day one.

Microservices: The most expensive way to solve a problem you might not have

Now the inconvenient truth that part of the industry is still fighting against: for most SMEs, microservices are the wrong choice. Not because the technology is bad, but because they solve a problem that you probably don't have and generate costs that you certainly do have.

The most prominent example of this comes not from a microservices sceptic, but from Amazon's engine room. In 2023, the Prime Video team publicly described how it had merged a distributed, serverless tool for audio and video quality monitoring back into a single, monolithic application, thereby cutting the operating costs of this component by around 90 per cent. Important to categorise: this affected a single building block, not Prime Video as a whole, and other parts of the service continue to run as microservices. But the lesson is clear. Even a company that seems to have invented microservices is deconstructing them where they were the wrong cut.

The maths is unromantic. Each microservice needs its own delivery, its own monitoring, its own troubleshooting across network boundaries. What is a simple function call in the monolith becomes a network call in the distributed system, which is slower and can break in new ways. A company with fifty development teams can easily bear this effort because it gets the team independence it urgently needs in return. A medium-sized company with eight developers only gets the effort.

The rule of thumb that we give customers in this situation: Microservices are an answer to an organisational problem, not a technology problem. If you don't have multiple teams that block each other when delivering, you don't have the problem that microservices solve. Then the modular monolith is almost always the better architecture, and you retain the option of removing individual modules later without having to buy them at a high price today.

API development: the connective tissue that determines success

There is a moment when every architecture decision comes under scrutiny: when the next system is to be connected. A new mobile app, a marketplace connector, an ERP change. This is precisely when it becomes clear whether the interfaces are sustainable or whether each connection becomes a small project in its own right. API development is therefore not the decorative part at the end, but the supporting structure. In a cloud architecture, services, databases, external systems and front ends talk to each other via APIs. If these are poorly designed, every bad decision is passed on to everything that depends on them.

An API-first approach reverses the usual order: You design the contract of the interface before you build the implementation behind it. This has a tangible advantage. The frontend, mobile app and third-party systems can be developed against the agreed contract while the backend is still being created. The interface becomes the basis for planning instead of a by-product, and the teams don't block each other because everyone knows what they can rely on.

Three principles that have proven themselves in practice:

• Contracts are binding, not incidental. An API is a promise to everyone who uses it. If the promise changes unannounced, integrations break by the dozen. Version consciously and document every change instead of silently rebuilding.
• Cut along the functionalities, not along the database tables. A good API maps what the user wants to do technically, not what the table looks like internally. This is the difference between an interface that people like to work with and one that everyone bypasses and replaces with their own workarounds.
• Treat security and rate limiting as part of the design. An open API without clear authentication and throttling is not an interface, but a gateway. Both belong in the design, not in a later round of hardening.

In short, a clean API layer is what keeps a cloud architecture extensible. It is also the point at which it will later be decided whether you can detach a module without pain or whether you will just tear it out of the rest with a crowbar.

The decision path: a pragmatic approach

Theory is of little help when the decision is due on Monday. That's why the path we recommend in practice is deliberately in this order, because each stage prepares the next.

First you clarify the business value per system, not the technology. Which application directly contributes revenue or differentiation, which is standard operation? This answer determines which of the 7 R's per system is correct. An interchangeable standard application belongs in "Repurchase" (buy a SaaS) or "Replatform", not in an expensive refactor.

Then you choose the migration strategy per system instead of across the board. No company can get by with just one of the 7 R's. A realistic portfolio mixes: most per rehost or replatform, a smaller part refactor for the strategic systems, a few legacy systems in Retire. If you refactor everything, you burn budget. If you only rehost everything, you will never realise the cloud benefits.

Only for the systems that deserve a real refactor does the architecture question arise. And the default is: modular monolith, clean-cut, with clear API boundaries. Microservices only where a demonstrable organisational or scaling problem justifies it, not because it sounds modern.

Plan for a cloud exit: what the EU Data Act changes from 12 January 2027

There is a deadline that hardly ever comes up in architecture discussions, yet it changes the maths of every cloud decision. The EU Data Act has applied since 12 September 2025. The cut-off that matters to you comes later, though: from 12 January 2027, providers of data processing services may no longer impose switching charges, including the charges for data export, known in the trade as egress.

This applies to IaaS, PaaS and explicitly to SaaS as well, regardless of whether the provider is based in the EU or is a US hyperscaler with customers in the EU.

Until then, a three-year transitional period applies (11 January 2024 to 12 January 2027), during which providers may still pass on the switching and export costs they actually incur.

A common misconception you will come across in specialist articles: "Since September 2025, there have been no more switching fees." That is not correct. September 2025 was only when the general obligations started to apply. Switching charges only drop to zero in January 2027. Details can be found in the European Commission's Data Act explainer. What remains permissible: standard service fees and agreed penalties for early termination.

There is one caveat, though. In its Digital Omnibus package, the European Commission has proposed specific amendments to the Data Act. Until amendments are adopted, the rules above apply, so check the current status before you rely on any change. The practical consequence is clear nevertheless: if you renew a cloud contract in 2026, negotiate the exit clause now, not in 2027.

And now for the part that concerns this article. The legislator takes the fee off your hands, not the technical lock-in. If your application relies heavily on proprietary managed services, provider-specific APIs and exclusive data formats, switching remains a rebuild project; it simply costs developer time instead of an exit fee. According to the Bitkom Cloud Report 2026, 59 per cent of companies cite precisely these lock-in effects as the biggest obstacle to switching, and only around one in three has ever switched provider.

This brings us full circle to the architecture question from the beginning. A modular monolith with clean interfaces and a thin, replaceable layer to the cloud services is not only easier to operate, it is also cheaper to leave. Portability is an architectural feature, not a contractual detail. If you are migrating today, sketch the exit path on a single page before the first managed service is booked. The answer tells you how expensive the dependency really becomes, even if you never leave.

Sovereignty, NIS-2 and C5: what has been added to provider selection in 2026

Three requirements now come into play before the architecture: they help determine which provider you may choose in the first place, and therefore which services you can build your architecture on.

The most far-reaching is the Cloud and AI Development Act, which the European Commission proposed on 3 June 2026 as part of its tech sovereignty package. The core for decision-makers is an EU-wide sovereignty framework with four levels, which public sector bodies are to apply based on their risk assessments:

• Level 1: processing and storage in the Union.
• Level 2: demonstrated independence from third countries, including transparency over the software supply chain.
• Level 3: EU ownership and control, including personnel criteria.
• Level 4: full transparency and control over the software supply chain.

Providers are recognised by the Member States after an audit. For an SME, this is not a compliance issue today; it is a selection criterion. If you supply public-sector clients, you may have to demonstrate your cloud provider's level in future. So far, this is a proposal in the legislative procedure; application dates in circulation are not official.

NIS-2 is no longer a thing of the future. The German implementing act entered into force on 6 December 2025. Entities in scope must register with the BSI, report significant security incidents and implement risk management measures. As of 30 September 2026, the BSI counted 20,141 NIS-2 registrations: 13,252 important and 6,837 essential entities, 1,447 of them from the critical infrastructure (KRITIS) sector, and 4,739 registrations from manufacturing alone.

The point that is regularly overlooked in migration projects: if you move applications to the cloud, you do not move the obligation to provide evidence with them. Supply chain and service provider management remain with your own company.

On top of that comes a detail with consequences for every tender. Since April 2026, the BSI criteria catalogue C5 has been available in the new version C5:2026, which for the first time specifically covers topics such as container management, post-quantum cryptography and confidential computing and addresses supply chain management in a more targeted way (BSI press release of 7 April 2026). For your requirements specification, this means that "C5 attestation" alone is now too imprecise. The version belongs in the requirements text.

All three end up in the same document as the exit clause, and they shorten the list of providers before you even start thinking about monolith or microservices.

Where it goes wrong: the costly mistakes

Three patterns keep cropping up, and all three cost real money.

The first is the big bang migration. Migrating and recutting everything at once, a deadline, fingers crossed. The picture is typical: Friday evening is the changeover day, on Monday half the company is at a standstill, and there's no going back because the old environment has already been dismantled. The reliable way is step-by-step: one system at a time, with the option of going back at any point. A migration without a way back is not a migration, but a leap without a net.

The second is the architecture that nobody has decided. Microservices because a newly hired developer knows them from their last job. A certain cloud service because it was just shown at a conference. A message queue because it is "sure to be useful later". Architecture that grows out of such individual decisions instead of a conscious choice becomes expensive and can hardly be dismantled. This was precisely the thesis at the beginning of this text.

The third is the forgotten cost control. The cloud charges per use, and that is both a blessing and a curse. A typical pattern: a test environment is started up and never switched off again, an oversized database node runs idle for months, and at the end of the quarter the management wonders why the cloud is more expensive than the old data centre. Without clear responsibility for costs, the bill grows silently because nobody owns the switch-off of unused resources.

This is not a fringe phenomenon: in the Flexera State of the Cloud Report 2026, the share of wasted cloud spend is 29 per cent, rising again for the first time in five years. Flexera attributes this to cloud-based AI workloads; that is the survey's interpretation, not a measured cause.

The scale behind it: 81 per cent of the more than 750 cloud decision-makers and users surveyed use generative AI, up from 72 per cent the year before. And according to the Bitkom Cloud Report 2026, cloud operating costs rose at 64 per cent of companies in the past year. Cloud cost control belongs in the project from day one, not as a clean-up operation when the first shock bill arrives.

The honest summary

Cloud migration and software architecture are one interrelated decision, and most mistakes occur because they are treated as two. Don't blindly move to the cloud and hope for an effect. Decide per system what it is worth and choose the migration strategy accordingly. For the few systems that deserve a real refactor, the modular monolith with clean APIs is the right architecture in the vast majority of midmarket cases, not what was advertised most loudly at the last conference.

The initial thesis was that migrations do not fail in the cloud, but because of an unmade decision. The reverse conclusion is the real good news: it doesn't cost any additional budget to make this decision consciously. It only costs to postpone it.

If you are faced with exactly this question and want an honest assessment instead of an architecture that happens to match the provider's favourite tool: This is the kind of decision where it's worth talking to someone who has built both sides. You can find out how we approach customised business software and system architecture and design on our services pages.

Frequently asked questions

What are the 7 R's of cloud migration? Rehost, Relocate, Replatform, Repurchase, Refactor, Retire and Retain: the framework of seven migration paths popularised by AWS. They differ in the degree of architectural change: Rehost moves an application unchanged, Refactor rebuilds it for the cloud, Retire switches off legacy systems.

Monolith or microservices: which is the right architecture? For most SMEs, the modular monolith is the best default: one deployable unit with cleanly separated modules. Microservices only pay off once several teams block each other when delivering; they solve an organisational problem, not a technical one.

How long does a cloud migration take? That depends less on the volume of data than on the path chosen for each system: a rehost of individual applications can be done in weeks, a refactor of strategic core systems is a project spanning months. The reliable approach is step by step: system by system, with the option to go back, instead of a big-bang deadline.