Context
An enterprise data platform rarely begins with a blank slate. Operational systems, data warehouses, integrations and reports already perform essential roles, while the need for new analytical and cloud capabilities continues to grow.
In this situation, the on-premise environment remained important. It hosted the core source systems and several data flows that needed to operate continuously and predictably. At the same time, the cloud introduced flexible options for processing, storage and analytics.
The aim was therefore not to build two separate platforms. What was needed was one data journey crossing two technology environments while preserving shared meaning, verifiable operation and clear responsibilities.
Hybrid operation was not treated as a temporary technical state, but as a deliberately managed architectural capability.
The architectural question
The central question was not which environment was stronger. It was how their roles should be divided while keeping the journey from source to use coherent.
This required clear answers to several connected questions:
- which data should remain on-premise;
- which processing should move to the cloud;
- where integration, historisation and quality controls should take place;
- how the same data could support both operational and analytical use;
- and how its meaning, origin and changes could remain traceable.
The boundary of the platform was therefore defined not by one technology, but by the complete information flow.
Constraints
The architecture had to fit into an operating enterprise environment. Several connected conditions shaped the design:
- different lifecycles across existing operational systems;
- the need for continuity and gradual adoption;
- security, network and data-management boundaries;
- the coexistence of batch and event-driven flows;
- requirements for traceability and repeatable processing;
- and the need to make new capabilities reusable beyond a single use case.
These were more than limitations. They showed where stable contracts were needed, where implementation could remain flexible and where operability had to become part of the design from the beginning.
Approach
Roles before locations
The first step was not to place components. It was to separate the platform’s responsibilities: source connectivity, ingestion, processing, persistent storage, semantic organisation and consumption.
Only then were those roles assigned to environments. Physical placement could therefore change without redesigning the meaning of the whole data journey.
Defined data exchange rules at environment boundaries
Versioned interfaces and verifiable data exchange rules described the connection points between on-premise and cloud components. They captured not only fields and formats, but also meaning, freshness expectations, quality rules and ownership.
This allowed the internal technologies of both environments to evolve independently while keeping data exchange predictable and verifiable.
Observability across the journey, not only at endpoints
Technical logs alone do not reveal whether business information has arrived in a usable state. Observability therefore covered every important stage of the journey: arrival, processing, quality, publication and readiness for use.
Architecture
The result was a layered data journey spanning both environments:
- 01Source and operational systems
- 02Integration and controlled ingestion
- 03Shared, historised data foundation
- 04Analytical and operational data products
Integration close to the sources provided stable connections to existing systems. Controlled ingestion separated the change cycles of the sources from the platform’s internal processing. The shared data foundation preserved history and lineage, while the serving layer shaped data for analytics, reporting and operational consumers.
Metadata, versioned mappings and consistent operational signals made the relationships between the layers visible.
Key decisions
Hybrid operation as a first-class architectural element
The connection between environments was not treated as a detour to be removed later. It received its own responsibilities, observability and change management. The platform could therefore follow the same principles through different stages of transformation.
Separate lifecycles for ingestion and consumption
A change in a source system did not need to trigger an immediate change in every report and data product. The shared data foundation and stable contracts separated the change cycles on the two sides of the platform.
Shared meaning travelling with the data
Business concepts, mappings and quality rules became parts of the platform alongside technical data movement. This allowed the same data to be interpreted consistently across different forms of use.
Outcome
The resulting structure provided more than a plan for one migration step. It created a platform that could evolve gradually.
- The roles of the on-premise and cloud environments became explicit.
- New data sources could connect through repeatable patterns.
- Analytical use became independent of direct source-system structures.
- Data origin, state and processing paths became easier to verify.
- Further cloud capabilities could build on existing contracts and operating principles.
The value was therefore not simply that data moved between environments. A shared operating model emerged for the entire data journey.
Lessons learned
The most important question in a hybrid data platform is not what remains on-premise and what moves to the cloud. That is a question of physical placement.
Lasting architectural value comes from clear roles between environments, stable contracts, traceable meaning and observable operation across the full data journey.
That is what turns a connection between two technology worlds into one understandable information system.