Trusted data for decisions
Change platforms without losing control of your data
Data Platform Migration & Open Architecture helps organisations plan and execute migrations in controlled waves. We assess dependencies, design for data portability, and use reconciliation and validation to manage risks to data quality, history and lineage. Each wave follows an agreed migration and cutover plan.
A senior lead replies within one business day. No obligation.
Slow, ageing or locked in
The platform is expensive, slow or reaching the end of support. Moving feels risky: years of history, reports people rely on, and dependencies nobody has fully mapped. And many migrations simply swap one lock-in for another.
What it costs: Rising licence and running costs, slow answers, and a second data world growing in spreadsheets.
What it sounds like:
“We don't want to renew our licence, but we're afraid to move.”
“Every data request takes weeks on our current platform.”
“We bought a platform, and the business still works in spreadsheets.”
“How do we move without losing our history?”
Open formats, controlled waves
We start with an inventory: what data and workloads exist, who uses them, and what depends on what. The target architecture uses open formats and standards, designed to keep your data portable across on-premises and cloud, warehouse, lake and lakehouse. The move happens in waves, each validated before the next, with parallel operation where feasible.
Why it matters:
- Less dependence on a single technology vendor.
- Controlled phases instead of one disruptive move.
- A plan designed to preserve historical data, metadata and lineage.
- The same data reused for reporting, analytics and AI.
- Future platform changes that aim to cost less and carry less risk.
What you get
Planning phase:
The planning phase covers agreed systems, workloads and dependencies. Its depth and duration depend on the complexity of the existing environment.
- Current-state inventory of data and dependencies
- Migration strategy and prioritised migration waves
- Open-format target architecture
- Source-to-target mapping
- Cutover, rollback or recovery, and decommissioning plan
Each migration wave (where execution is in scope):
- Data reconciliation and quality validation
- Migration of metadata and lineage, at the depth agreed in the plan
- Cutover and, where planned, decommissioning
Typical first result
An assessed migration scope, a target architecture and a phased migration plan.
A senior lead replies within one business day. No obligation.
How it works
- Assess and plan.Review the agreed migration scope, identify critical dependencies, define the target architecture and prioritise migration waves. A focused initial assessment typically takes 2–4 weeks. You decide whether and how to proceed.
- Migrate in waves.Migrate prioritised workloads in controlled waves. Validate data and functionality against agreed acceptance criteria. Where feasible, maintain parallel operation until cutover conditions are met.
- Cut over and decommission.Wave by wave, with a rollback or agreed recovery approach for each step.
For technical leads: depending on the target architecture, we consider open technologies such as Apache Parquet for columnar data storage, Apache Iceberg for table management, open APIs for integration, and OpenLineage for lineage metadata. These are examples, not mandatory components of every migration.
Current platform, then an open-format transition layer, then validation and reconciliation, then the target platform, with parallel operation where feasible underneath.
- FromCurrent platform
- Wave by waveOpen-format transition layer
- Each waveValidation and reconciliation
- ToTarget platform
Parallel operation where feasible
Who does the work
A senior DataOfis architect leads the assessment and the migration design. Data engineers from our network, or delivery partners under DataOfis design and oversight, carry out the migration waves. We have no platform to sell, so the target follows your workloads.
Working together
- Indicative duration: typically 2–4 weeks for a focused initial assessment and plan. Execution depends on scope and platform complexity.
- Scope boundary: this service covers migration strategy, architecture and the transition of workloads. Building and running a new data platform is part of Data Ecosystem Delivery & Support; if both are needed, their responsibilities are defined separately.
- What DataOfis is responsible for: the agreed planning deliverables, then the agreed deliverables of each migration wave. Where a partner carries out the work, DataOfis is responsible for design and oversight.
- Bought on its own: the plan stands alone. You can carry it out with your own team, with us, or with another provider.
Questions we often hear
No. The target architecture follows your workloads. We have no platform to sell.
Where feasible, yes. Parallel operation can need extra synchronisation, infrastructure and running costs, so the plan sets out where it makes sense.
The plan covers historical data, metadata and lineage, and each wave is reconciled and validated against the source to manage that risk.
Either. The choice follows your workloads, regulation and cost. Open formats keep both options open.
Often combined with
Plan your move
Tell us about your current platform and what's driving the change. We'll discuss what a planning phase would cover.
A senior lead replies within one business day. No obligation.
Need the new platform built and run? Data Ecosystem Delivery & Support