Example of Cloud Migration in SMEs

Monday morning begins with a production alert: The customer portal is responding too slowly, the overnight import has failed, and an administrator must manually access a server for a hotfix. This example of cloud migration in mid-sized companies shows why this is rarely just an infrastructure problem. Those who only relocate servers carry existing bottlenecks with them. In contrast, modernizing architecture, operations, and delivery processes creates a solid foundation for growth.

This anonymized yet typical scenario concerns a German manufacturer with around 500 employees. Sales, service partners, and customers use a central portal for orders, spare parts, and technical documentation. The application runs on virtual machines in its own data center. Releases occur every six to eight weeks, capacities are planned long-term, and operational experience is concentrated in a few individuals. The platform is business-critical, but it increasingly hampers business operations.

Initial Situation: The server is not the real problem

The existing platform fundamentally works. This makes decisions difficult: There is no obvious total failure that forces an immediate replacement. At the same time, operational friction losses are accumulating. Development and testing environments differ from production. Deployments involve hand-tuning and coordination across multiple teams. Security updates compete with specialized requirements for limited maintenance windows.

Additionally, there is a typical cost problem: The hardware is designed for peak loads that occur only a few times a year. In everyday operations, a significant portion of the capacity remains unused. New features, such as a dealer area or interfaces for large clients, require additional infrastructure and prolong the lead time. Therefore, the question is not: "Do we need to move to the cloud?" It is: "Which operational and business bottlenecks do we want to specifically eliminate with the migration?"

For the company, four measurable objectives were defined: Releases should be shortened from several weeks to a few days, critical outages should be detectable earlier, seasonal loads should be managed without manual intervention, and costs per platform should be transparent. These objectives prevent the migration from becoming a technical project without verifiable benefits.

The Example of Cloud Migration in Mid-Sized Companies: The Realistic Target State

A common mistake would have been to move the virtual machines unchanged to a cloud provider. This lift-and-shift approach can be sensible if a data center needs to be vacated quickly or dependencies are initially unpredictable. It reduces the effort at the start, but does not eliminate manual deployments or missing transparency. Moreover, permanently running oversized instances in the cloud can become expensive.

In this example, a stepwise target state was therefore defined. The web application and its background jobs were containerized. Static content and documents were moved to an object storage. The relational database initially remained as a centrally managed service, instead of being prematurely divided into many technical components. This reduced operational effort and minimized risk for the first migration phase.

The containers run on a Kubernetes platform designed for productive workloads. Importantly, Kubernetes is not the end goal itself. What matters are standardized deliveries, clearly defined resources, controlled scaling, and an operational model that works even during vacations, personnel changes, or incidents. For smaller applications, a managed container platform can be the more economical choice. The suitable technology depends on the load profile, team competence, integrations, and availability requirements.

Migration in Controlled Stages Instead of a Big Bang

The technical switch did not begin with a cutover date, but with a reliable inventory. The team identified dependencies on ERP, identity providers, email dispatch, file shares, and external partner interfaces. Data flows were particularly relevant: What data leaves the company, where is it processed, and what retention or protection requirements apply?

Subsequently, the cloud foundation was built. Network segments, access roles, encryption, logging, and backup rules were versioned as infrastructure code. This avoids the creation of undocumented setups that only a few administrators understand. Changes can be audited, repeated, and traced. At the same time, security is integrated into the deployment process, rather than being scrutinized just before going live.

First Deliver Reproducibly, Then Switch to Production

Alongside the infrastructure, a CI/CD pipeline was established. Every merge triggers automated tests, security checks, and the build of a versioned artifact. Deployment to test and staging environments follows the same process as later in production. This reduces errors from differing configurations and creates a clear rollback option if a version causes problems.

A replication was set up for the database. While the old platform continued to run, the data was synchronized to the new environment. Functional tests, load tests, and a recovery test showed not only if the application starts but also whether it operates reliably under real conditions. Only after metrics, interfaces, and operational processes were confirmed, did the switch occur during a scheduled maintenance window.

A big bang would have been unnecessarily risky here. The stepwise migration required more discipline with interfaces and data reconciliations. However, it kept the platform available during the transformation, and the team could correct assumptions based on real operational data.

Operations are Part of the Migration, Not the Phase After

After going live, the real work begins, which determines success. In this example, technical metrics such as response times, error rates, database load, and resource utilization were linked to business signals. These included failed orders, delayed imports, and undelivered confirmations. A dashboard alone does not resolve an incident. However, it creates the conditions to narrow down causes earlier and alert responsible parties specifically.

The readiness was also clearly defined: Which disturbances need to be addressed immediately, which can wait until the next business day, and who decides on a rollback? Runbooks document recurring processes such as restoring a backup or analyzing a failed deployment. This is not bureaucracy. It reduces dependence on individuals and makes reactions under time pressure more reliable.

The results in this example are not measured solely against cloud services. What matters is the workflow: New features can be delivered multiple times a week after automated checks. Peak loads during a spare parts campaign are managed through scaling rules. Disruptions are assessed based on defined service level goals. And the internal team invests less time in manual maintenance because repetitive tasks are automated.

Cloud Costs Must Remain Manageable

More flexibility does not automatically lead to lower costs. In the cloud, consumption becomes visible and variable. Without clear responsibilities, there are often permanently running test environments, oversized databases, or unused storage capacities. Therefore, FinOps was integrated into the implementation from the start.

In the scenario, costs were assigned by environment, product area, and responsible team. Budgets and alert thresholds made deviations visible early. Resources received binding tags, and non-productive environments were shut down outside required times. For predictable base loads, the company reviewed discounted usage models, while variable loads remained intentionally flexible.

It applies that the cheapest configuration is not always the most economical. A smaller database instance can reduce costs, but at high utilization, it may worsen the user experience and create operational work. Therefore, FinOps does not mean simply saving. It means linking technical decisions with consumption, risk, and business benefits.

What Mid-Sized Companies Should Take Away from the Example

The migration was successful because it was not an isolated infrastructure project. Business goals, application architecture, security requirements, delivery processes, and operations were considered together. Where internal capacities are limited, a partner is needed who does not drop out after the architecture workshop but takes responsibility until production-ready operations are achieved. devRocks connects this perspective from engineering, automation, and ongoing platform operations.

The most sensible first step is rarely the selection of a cloud product. It is an honest assessment of the critical application: Which failures really cost money? Where are teams waiting for manual approvals? What load is predictable, and what is volatile? And which competencies should be built internally over the long term? Those who answer these questions concretely can tailor a migration so that it not only delivers new infrastructure but also works faster, safer, and more economically in daily operations.