Cloud migration is far more than just a technical shift. In this interview, Anja Kammer explains why strategy, organization, and architecture must be considered together – and how successful migrations can be achieved in practice.
Cloud migration is often seen as a purely technical topic – but you emphasize organization and architecture as well. Why is it so important to consider these aspects together?
Cloud migration is not just a technology shift. Of course, topics like cloud platforms, containers, or orchestration play an important role. But focusing on these alone does not lead to a successful migration. It is equally important to consider whether the architecture fits the new operating model and whether the organization is capable of handling this transformation.
Cloud environments are dynamic, distributed, and in many ways more volatile than traditional infrastructures. This requires architectures designed for resilience, scalability, and loose coupling. Simply moving existing structures into a new technical environment without addressing these aspects often means carrying over old problems.
The organizational side is just as important. In practice, migrations often fail not because of technology, but due to unclear responsibilities, missing processes, or the lack of a cloud-native culture. New technologies bring new requirements for teams, responsibilities, and collaboration. This also includes aspects such as training, compliance, data protection, and shifting power structures between roles and departments.
Cloud migration should therefore be understood as a socio-technical transformation. Technology, architecture, and organization are closely intertwined – and only by addressing all three together can a migration succeed in a sustainable way.
Many companies start a cloud migration without a clear strategy. What are the key elements of a solid planning phase?
A good planning phase always starts with a thorough understanding of the current situation. While this may sound trivial, it is often underestimated in practice. Instead of looking only at the system as a whole, each application, module, and relevant component should be examined individually. For example, it is important to understand whether sensitive data is processed and which regulatory requirements apply.
The goal is to create transparency: What applications exist? What databases, infrastructure, interfaces, and dependencies are involved? Requirements related to performance, security, and compliance must also be considered. In the end, there should be a clear and realistic picture of the system landscape.
Next, the migration must be placed in a broader context. A cloud strategy does not exist in isolation but is part of the overall IT strategy and business objectives. There may already be guiding principles, such as replacing certain products or platforms. Accordingly, the right stakeholders need to be involved – from IT and operations to architecture and project management, as well as business units, compliance, and finance.
Based on this, applications can be evaluated and prioritized according to cost, benefit, risk, and complexity. This leads to pilot candidates and a meaningful sequence of migration steps. For each application or component, an appropriate migration path is then defined. Ideally, the result is not a seemingly precise master plan, but a realistic overview of phases, milestones, and dependencies.
You mentioned risks, prerequisites, and migration waves – how can teams turn these into a truly viable migration plan in practice?
In practice, it has proven effective not to start with a big bang, but to begin with a few pilot components. For these, teams can analyze in detail which steps are required, what risks exist, and which prerequisites must be met. It is also important to document decisions in a transparent and traceable way.
For individual components, the main phases and activities should then be outlined. These do not need to be defined down to the last detail from the beginning, but critical milestones, dependencies, and potential blockers must be visible. Dependencies in particular are often hard constraints in planning. For example, migrating a database may require resolving certain technical debts first.
An incremental approach also helps to reduce risks. If a full modernization is too complex or controversial, an intermediate step such as replatforming (following the “6 R’s”) can be a sensible option before undertaking a larger transformation. These staged approaches make the plan more realistic.
Over time, individual plans evolve into a roadmap with migration waves, where dependencies, critical milestones, and priorities can be better aligned.
The “6 R’s” are a well-known model for cloud migration. How can teams use this concept effectively without applying it too rigidly?
From my perspective, the 6 R’s are primarily a useful structuring framework. They help teams systematically evaluate migration options and structure discussions. Problems arise when the model is applied as a rigid scheme.
It is particularly important not to define a single strategy for an entire system. In practice, it is almost always more effective to decide per application or even per component. Different parts of a system often have very different requirements, risks, and potential.
The 6 R’s do not provide the answers themselves, but rather the right categories to develop them. What really matters is the reasoning: What are our goals? What constraints apply? What risks are acceptable? And where is the effort justified? This is where the model becomes valuable, as it makes trade-offs visible – for example between speed and perfection, or between short-term relief and long-term modernization.
When a company has to decide whether to optimize existing systems, build new ones, or replace them entirely – which factors should be considered most carefully?
The first question should always be: what is the actual goal? Is it about increasing flexibility, internationalization, automation, faster delivery of new features, or replacing outdated technologies? Without a clear goal, discussions about optimization, redevelopment, or replacement remain abstract.
There are also hard constraints that influence decisions, such as regulatory requirements, data residency, or contractual obligations. The economic perspective is equally important: What costs will arise? What benefits are realistic? What risks are associated with each option?
Technology also plays a role, particularly the cloud readiness of existing systems. Some applications can be adapted relatively easily, while others are heavily tied to legacy technologies. Depending on the situation, rehosting, replatforming, or more extensive refactoring may be appropriate. Especially when dealing with sensitive data, moving to the public cloud often requires additional effort due to security and compliance considerations.
Finally, the organizational aspect must not be overlooked. Even the best technical target architecture is of little use if the necessary skills, responsibilities, or operating models are missing. Existing knowledge and the willingness to adopt new forms of ownership and collaboration should therefore always be part of the decision-making process.
What common mistakes do you see in cloud migrations – and how can teams avoid them from the start?
A common mistake is that organizations start too quickly. The decision to “move to the cloud” is made, but the actual strategy work has not yet been done. This leads to a lot of activity, but little direction. My recommendation is always: first create transparency, then evaluate and prioritize – and only then define concrete migration paths.
Another typical mistake is treating migration purely as a technical issue. Organizational impacts, new roles, learning efforts, and compliance requirements are often considered too late. In practice, success depends heavily on involving all relevant stakeholders and treating the transformation as a shared effort.
It is also problematic to define a single migration path for an entire system. This rarely works well. It is more effective to take a differentiated approach per component, start with pilot candidates, and learn from the first steps.
Finally, I often see a tendency toward perfectionism that slows down the entire process. Not every application needs to become fully cloud-native immediately. In many cases, a pragmatic intermediate step is the better solution, especially if it helps reduce risks and enables progress in the first place.
The key is to make dependencies visible early, take sensitive data seriously, and approach migration as an iterative learning process.
More on this topic at the Software Architecture Forum 2026: There, Anja Kammer will show in her session how to strategically plan and successfully implement cloud migrations.
