In our projects, we repeatedly see companies equating migration with redesign. This is a misconception. Simply transferring a monolithic data model unchanged to the cloud only shifts bottlenecks – it doesn't solve them. Architectural decisions must be made before migration. Otherwise, the cloud remains merely a new location for old structures.
The Problem of Classic Application Architectures
In many organically grown systems, the relational database performs several roles simultaneously:
- Transaction system
- Integration hub
- Reporting foundation
- Storage for large binary data sets
- Almost always the carrier of business logic
This concentration creates dependencies. Every change affects the central system. Every scaling requirement impacts all workloads.
The result:
- Scaling is primarily vertical
- Maintenance windows affect the entire system
- Performance tuning becomes complex
- The pace of innovation slows
The database transforms from a stabilizing core into a structural risk.
Modern Architecture: Thinking about Data According to Access Patterns
Modern cloud architectures don't just separate services—they separate data according to its nature.
What matters is not just the relational model, but the access pattern.
Not all information needs to be treated the same.
Hot Data
Data with extremely low latency requirements and high access frequency, such as session information or short-term status data.
Key-value models or cache clusters are suitable for offloading core systems and maintaining consistently low response times.
Warm Data
Operationally relevant data with clearly defined access patterns that do not necessarily require relational structures—for example, event or time-series data, graph relationships, or highly scalable key-value structures.
Specialized database systems can support horizontal scaling and specific query patterns more efficiently than a central relational model.
Cold Data
Historical or analytical data with lower access frequency but high volume.
Efficiency, cost structure, and analytical usability are paramount here—for example, through relational platforms, data warehouse approaches, or data lake models.
Designing Complexity Deliberately – Not Increasing It
Dividing data into multiple specialized models does not automatically mean less complexity. On the contrary: More systems initially increase the number of technical components.
Therefore, the crucial factor is not the number of databases, but the clarity of their roles.
A modern data architecture only works if:
- Responsibilities are clearly defined
- Data flows are transparently documented
- Security and governance models are implemented consistently
- Monitoring and observability are systematically established
Redesign does not mean multiplying systems.
Redesign means deliberately decoupling workloads and distributing complexity in a structured way, instead of concentrating it centrally.
This does not make the architecture simpler – but it does make it more manageable.
Target Schema Instead of 1:1 Adoption
An architecture redesign does not begin with a tool, but with modeling decisions.
Key questions are:
- Which data requires strong transaction consistency?
- Which workloads can be decoupled?
- Which data must be highly available – and which does not?
- Where do bottlenecks arise from centralized storage?
The goal is not fragmentation for fragmentation's sake.
It's about a deliberately structured data landscape in which each system plays a clearly defined role.
Only once this target architecture is defined does the next step follow: migration.
Architecture follows not only technology, but also organization
Not every organization immediately needs a highly differentiated multi-database architecture. The target structure must be appropriate to the business complexity, the data volume, and the organizational maturity.
A differentiated data landscape requires:
- clear ownership models
- defined operational processes
- sound database and platform expertise
Redesign therefore does not mean maximum diversification, but appropriate structuring. In some scenarios, a cleanly scalable relational platform is sufficient. In other cases, the separation of workloads is essential.
Architectural decisions are not a technology demonstration.
They are a conscious balancing act between business needs, organizational capacity, and economic constraints.
Architectural work before migration projects
A migration without prior redesign merely transfers existing bottlenecks to a new environment. Only when architecture, data models, and workload distribution are consciously defined can a migration reach its full potential.
At PROTOS, we understand this step as strategic architectural work. Technology follows design—not the other way around. The operational transfer of legacy database monoliths to this target architecture is the next logical step.
