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 reducing the operating costs of this component by over 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 binding 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.

Where it goes wrong: the costly mistakes

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

The first is the big band 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 up and running, 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. 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.