Move your data without losing trust, lineage, or business continuity
Migrations look like technology projects. They are change management projects with a technology layer. DI Squared has guided more than 200 companies through data work since 2008, including warehouse migrations, BI platform consolidations, and the full retirement of legacy reporting estates. We move your data, your semantic layer, and your reports without breaking the business that depends on them.
Snowflake, Databricks, Azure, AWS fluent
HQ Atlanta, serving US, Canada, Europe
- We migrate data warehouses, BI platforms, and reporting estates
- Common moves: legacy warehouse to Snowflake/Databricks, QlikView to Qlik Sense, Tableau/Power BI/Qlik consolidations
- Method: Discover, Map, Navigate, Adjust
- We protect trust, lineage, and business continuity through cutover
- Typical first step: a migration assessment and risk audit
What is a data migration project
A data migration project moves data, transformation logic, semantic models, and the analytics built on top of them from one environment to another. The most common cases: a warehouse migration (for example, Oracle or Teradata to Snowflake), a BI platform migration (for example, QlikView to Qlik Sense, or Tableau to Power BI), a cloud migration (on-premise to Azure or AWS), or a consolidation (multiple legacy reporting estates collapsing into one).
The technical work is real, but it is the smaller half. The harder half is preserving trust: making sure the numbers reconcile, the lineage is intact, the audit trail is preserved, and the people who depend on the reports keep getting what they expect on the day of cutover. DI Squared treats migration as a change management discipline first and a technology discipline second.
What we migrate
The most common engagements: warehouse migrations (legacy to Snowflake, Databricks, or a cloud-native warehouse), BI platform migrations (QlikView to Qlik Sense, cross-platform moves between Qlik, Power BI, Tableau, and Looker), reporting consolidations (multiple legacy estates into a single governed environment), cloud migrations (on-premise to Azure, AWS, or Google Cloud), and semantic layer modernizations (legacy cubes or proprietary models to dbt and a modern warehouse).
We also do the partial migrations: a single source system, a single subject area, a single department’s reporting. Sometimes a phased migration is the right answer, and the project is to plan the phasing as much as to execute the first phase.
Platforms and migration paths we know well
Our Qlik bench is deep, so QlikView to Qlik Sense migrations are a recurring engagement. We also handle Tableau, Power BI, and Looker migrations in both directions. On the warehouse side, we are fluent in moves to Snowflake and Databricks from legacy platforms (Oracle, SQL Server, Teradata, Netezza, Vertica), and from legacy lakes to modern lakehouse patterns. dbt is our default transformation tool on the destination side. We are vendor-neutral, but fluent in the platforms that matter.
How a migration engagement runs
Discover (two to six weeks).
We inventory what exists: data sources, transformations, reports, users, dependencies, and the business calendar the work has to fit. We expose the risks before the plan is written. Most migration cost overruns trace to risks that were visible in Discover but were not addressed.
Map (four to eight weeks).
We document the migration plan, the reconciliation strategy, the rollback approach, the change management plan, and the cutover sequence. This includes a retire-or-rebuild decision for every report and pipeline in scope. Many legacy artifacts should not be migrated. They should be retired.
Navigate.
We execute the migration in waves, with reconciliation at every wave boundary. Users are moved in cohorts, not all at once. Each cohort validates that the new environment is producing the expected numbers before the next cohort moves. The legacy environment runs in parallel until cutover is complete.
Adjust.
Post-cutover stabilization, decommissioning the legacy environment, and the first wave of net-new build on the new platform. Most clients use the migration as the moment to fix what the old environment never let them fix.
Where we have done this work
Migrations are particularly common in utilities (operational data platforms aging out), healthcare (regulated platforms moving to cloud), manufacturing (legacy on-premise stacks moving to lakehouse), retail (consolidating acquired-company reporting), financial services (warehouse modernization under audit constraints), and energy (legacy trading and operational platforms migrating to cloud). From life science to lifestyle, the migration playbook is the same in shape, even when the data is not.
See industries for industry-specific notes and case studies for engagement detail.
Data Migration Services, answered.
Q: How long does a data migration take?
A: It depends on scope and business calendar. A focused BI platform migration on a clean warehouse can ship in three to six months. A full warehouse migration with reporting cutover usually runs nine to eighteen months. Multi-platform consolidations can run longer. The biggest variable is not technology; it is how much legacy logic is retired versus rebuilt versus migrated as-is.
Q: Can we lift and shift, or do we have to rebuild?
A: Most migrations are a mix. Some logic can be ported with minimal change. Some has to be rewritten because the new platform does not support the old pattern. Some should be retired because it never should have been built in the first place. Mapping out the lift-versus-rebuild-versus-retire decision per artifact is one of the main deliverables of the Map stage.
Q: How do you handle reconciliation?
A: Reconciliation is a first-class workstream from day one. We set tolerance thresholds with the business, build automated checks at every transformation boundary, and reconcile by report and by user cohort before cutover. Trust is the deliverable. Numbers are the means.
Q: What about the legacy environment?
A: It runs in parallel through cutover and the first stabilization period after. We decommission only after the new environment has been load-bearing for at least one full reporting cycle. Premature decommissioning is one of the most expensive mistakes in a migration program.
Q: Do you do QlikView to Qlik Sense migrations?
A: Yes, and it is one of our most common migration engagements. We are a Qlik Elite Solution Provider and a three-time Qlik Solution Partner of the Year. We have a tested playbook for the rebuild-versus-port-versus-retire decision per QlikView app, the semantic model redesign, and the user cohort cutover.
Q: Can you migrate while we keep delivering new analytics?
A: Yes, with discipline. We staff a “lights-on” lane for the in-flight requests during migration. The default posture is to defer net-new build that is dependent on the legacy environment, and to channel net-new build into the new platform from a defined point in the timeline.
Migrate without losing what you built
Whether it is a warehouse, a BI platform, or a full reporting estate, the goal is the same: move the data, keep the trust. We will assess the risk, document the plan, and run the cutover alongside your team. Since 2008.