A Practical Guide to Data Migration Consulting vs In-House

Cost is not the first question you should ask when planning a data migration. The first question is whether anyone on your team has finished a migration like this before. Next is how much translation work is within the source system. These two answers help determine whether hiring outside migration consulting earns back its fee or wastes your budget on something you didn't even need.

The rule of thumb is simple. Run the migration yourself when the platforms are closely aligned, and someone on your team has already completed or managed a similar migration. Bring in an external data migration consultant when a fixed deadline or proprietary source system exceeds your team's capacity. Use a hybrid model for everything in between.

This article explains what a migration involves, what each delivery model can cost, and how to judge which approach best fits the system you are moving.

Moving the data is a small part of the migration. Most of the time goes into three other jobs. Finding what depends on the data, converting logic the target platform does not understand, and proving the new system returns the same answers.

Most teams underestimate the first job. Ironically, understanding application dependencies is the top-ranked migration barrier, ahead of technical feasibility and cost. The table below splits the same project into seven phases.
NOTE: Treat the ranges as a planning aid rather than a measured average, because proportions move with the platform pair, the code volume, and the consumer count.

Each phase carries different work:

• Inventory and Discovery: Finding the tables, jobs, procedures, reports, and undocumented workloads nobody has looked at in years.
• Translation: Converting proprietary SQL, procedural logic, and scheduling rules into something the target runs correctly.
• Semantic Layer: Rebuilding business definitions and metrics so a revenue figure still means the same thing.
• Downstream Consumers: Repointing BI tools, applications, and operational feeds, then fixing what breaks.
• Validation: Comparing counts, aggregates, and edge cases between the old system and the new one.
• Cutover: Deciding when the target becomes authoritative and when the source can be switched off.

Discovery and validation together can outweigh every other phase. An estimate built on data volume alone misses both, which is how a six-week plan becomes a five-month project.

These seven phases clarify how much work is needed. Scoring tells you how much of it your own project carries. Give the project 0, 1, or 2 points on each factor below, then total it.

A total of 0 to 4 points means you can run the migration in-house. If the total is between 5 and 9, it’s an ideal fit for the hybrid model. Anything from 10 upwards would mean external data migration consulting will cost less than the rework.

NOTE: The bands are just a starting point, not a formula. A borderline total means re-examining your two highest-scoring factors.

Each band above names a delivery model, and the three cover almost every migration project. All three run the same seven phases and differ only in who does what. Some rows below favor keeping the work in-house.

An in-house data migration is the right call more often than consultancies admit. Run it yourself when most of the following hold true:

• Source and target are both modern cloud platforms with high SQL compatibility.
• No external deadline forces the cutover date.
• Someone on the team has completed a comparable migration.
• The team has real capacity, not borrowed evenings.
• Validation can be designed and owned internally.

Every item on the list removes a named risk. Compatible platforms shrink the translation phase to near zero, and a small consumer count keeps dependency discovery to a week rather than a quarter. A flexible deadline turns a week-six surprise into lost time instead of penalties.

The strongest argument for keeping the work inside arrives after the project ends. A second migration is coming for most teams, and the first one writes the internal playbook. The team can write its own reconciliation tooling and cutover runbook, and then use them into the next project. Hiring a consultancy here will just add cost, nothing else.

Every condition above assumes someone is driving the project. Without a named driver, four patterns show up repeatedly, and none is about engineering skill.

• Priority Erosion: The migration competes with the roadmap in every sprint and loses quietly. The slip arrives by attrition rather than by a decision anyone made.
• Single-Point Knowledge: One engineer carries the dependency map in their head. A resignation in month three restarts discovery.
• Estimating Only What is Visible: Teams size the transfer and the schema, because both are legible. Translation and validation are the larger share, and they land later as overrun.
• Self-Marked Validation: The people who built the migration also design the tests for it, so a wrong assumption survives both.

None of the four argues against running the migration yourself. Each one argues for naming a single owner and writing decisions down while they are fresh. Each one also argues for putting the validation plan in front of someone who did not build it.

A named owner and a reviewed validation plan may handle the four patterns mentioned above, but they might not be able to handle the four conditions below, each of which removes your margin for error.

A Hard External Deadline

A fixed date is the first condition, and it usually comes from outside the data team. License expiry, a data-center exit, an acquisition close, and hardware retirement all remove your ability to slip. Experience pays most against a fixed date. An experienced team spends less of the schedule discovering problems and more of it fixing them.

A Proprietary Legacy Source

The source platform is the second condition. Someone has to know what the proprietary behavior is and not what the code says. Teradata customers face the sharpest version of the problem. Many are weighing another expensive renewal against a multi-year rewrite.

The Internal Team is Already Committed

Capacity is the third condition, and it decides the schedule more often than skill does. Migrations compete with revenue work, and they lose. If the two engineers who understand the warehouse are also the two shipping the roadmap, the migration slips every quarter until the deadline forces it.

A Previous Attempt Has Stalled

A stalled project is the fourth condition, and it changes the question being asked. The work is no longer how to migrate. It becomes why progress stopped, which dependencies were missed, and whether anyone defined what “done” means.

Diagnosis rewards pattern recognition. An outside team has seen the same stall on three other projects, so it finds the cause faster. Most stalls trace back to a short list of reasons, and we cover why migrations fail in a separate piece.

None of the four conditions forces you to hand over the whole project. The hybrid model splits it instead. An external lead designs the target architecture and sets the conventions. The same lead builds the validation framework, then delivers the first end-to-end vertical slice. Your team executes the remaining slices against the same conventions.

The split follows the risk. The external side owns architecture, translation approach, validation, runbooks, and cutover criteria. Lack of experience costs the most on all five. Your side keeps business knowledge, data ownership, and most of the execution. The people who will run the system afterwards build it.

IMPORTANT: If your side has no capacity to run the remaining slices, the pattern has nobody to follow it, and you have paid for documentation.

All three models carry a price. Consulting is the easiest to quote, because it is priced on scope and risk transfer rather than on data volume. Four commercial models cover most engagements:

• Fixed Fee: Priced after an assessment, which is why any serious firm profiles your data before quoting.
• Time and Quality: Flexible, and appropriate when the source system is poorly understood.
• Milestone-Based: Payment attached to delivered slices and passed quality gates.
• Retainer or Advisory: Architecture and review only, with your team building.

Published ranges vary widely because scope does. A Teradata to Snowflake migration is quoted at $30,000 to $80,000 for a small environment and $150,000 to $500,000 for a mid-sized one. This range lines up with the effort we cost out in our migration tools roundup. Estates over 100 TB run above $500,000. Price yours from an assessment.

Two inputs move the quote more than the rest. Object count and procedural code volume set the translation effort, while downstream consumer count sets the remediation effort. Validation depth, cutover complexity, and parallel-run duration fill in the remainder.

Consulting fees arrive as one invoice. In-house costs arrive in three separate places, and all three get missed:

Fully Loaded Labor: The true cost of an employee runs 1.25 to 1.4 times base salary once payroll taxes, benefits, and overhead are counted. Four engineers at $140,000 base, running half-time for five months, cost roughly $146,000 to $163,000 before anyone buys a tool.

Tooling and Environments: Migration tools, validation tooling, temporary environments, monitoring, and the target platform's compute during testing.

Dual-Run Licenses: While the migration runs, you pay for the legacy platform and the target at the same time.

The third item is the painful one. If the legacy contract is non-cancellable and renews annually, a three-month overrun can cost more than the consulting fee you declined. Check the arithmetic yourself. Multiply the monthly legacy license and support cost by the months of expected overrun. Then, set the result against the proposal on your desk to arrive at a decision.

NOTE: Opportunity cost belongs in the same column. Five months of senior engineering time on migration is five months not spent on the roadmap.

Tooling sits inside both budgets. The tools a firm names tell you how much of this work it has done. Four appear on most modern migrations, each covering a specific phase:

• SnowConvert AI: Snowflake's free conversion tool for legacy code, covering Oracle, SQL Server, Teradata, and Redshift. It also includes BTEQ scripts and stored procedures. Snowflake states it can automate more than 96% of code and object conversion, though every converted file still needs review.
• AWS SCT and DMS: The Schema Conversion Tool handles schemas and code objects. DMS Schema Conversion is now the recommended route for supported OLTP paths. AWS DMS moves the data and keeps the target in sync through change data capture during testing.
• Datafold: Cross-database diffing compares source and target at dataset, column, and row level using checksumming rather than full extracts. The open-source data-diff project was deprecated in May 2024, so the current path is Datafold Cloud.
• dbt: Where the transformation layer gets rebuilt as version-controlled, tested models. dbt Core v2.0 with the Fusion engine shipped under Apache 2.0 on June 1, 2026, alongside the completed Fivetran and dbt Labs merger.

All four stop at the same place. None of them converts a business definition or decides which of the three systems holds the authoritative customer address. 

Takeaway: A firm that volunteers the same limits before you ask has run these projects. A firm promising automation end to end has not.

Naming the tools is one filter. The scope document is the other, and it separates a priced project from an open-ended one. At minimum, it should state:

• Source platforms and versions, plus the target platform
• Object counts, data volumes, and known downstream consumers
• Transformation and translation complexity
• Migration phases, milestones, and deliverables
• Cutover approach and rollback requirements
• Knowledge-transfer requirements

Validation belongs on the list as a deliverable rather than an activity. A validation framework, a test suite, and a reconciliation report can each be accepted or rejected on delivery. “We will test thoroughly” cannot.

Exit criteria belong in the contract for the same reason. Reconciliation thresholds, performance thresholds, and business-user sign-off all need real numbers written against them. Name an owner for the cutover decision too.

Handover is the last clause worth arguing over. The biggest weakness of any external engagement is that the expertise walks out once the invoice is settled. Architecture documentation, migration scripts, the validation framework, runbooks, and time with your operators all belong in the statement of work. Leave them out, and you have rented the knowledge. The rest of what's worth arguing over sits in CTO's guide to data migration consulting.

Validation earned its own line in the scope document for a reason. “The data arrived” and “the new system behaves correctly” are different claims, and only the second matters at cutover. Row counts confirm the first.

Proving the second is slower. It takes aggregate comparisons, business-rule checks, and validation of the schema and its transformations. Report reconciliation and performance testing come next. A parallel run then checks that both systems produce the same month-end numbers.

Ownership of the validation work should be explicit. Whoever built the migration should not be the only party signing off on it, which is why business users run acceptance testing on their own workflows. The same separation applies to a data platform, and a data lake testing checklist sets out the layers that need it.

Real project numbers make the effort easier to understand. Public case studies with detailed figures are rare, but Next Pathway’s national retailer project provides a good example. The retailer had to move from Teradata to Snowflake on a fixed deadline.

The project covered 2.5 million lines of Teradata code, 62 million lines of code in ETL jobs, and 2,000 BI reports across five tools. UAT-ready code was delivered in six weeks, and the full migration was completed in 150 days, 37% faster than the original manual estimate. The data itself was not the main challenge.

The assessment score points at one of three models, and the situations below are what each score usually looks like in practice.

The score, the phase table, and the cost arithmetic all measure the same five things. Team experience, translation volume, downstream count, capacity, and the cost of running late decide which model fits. Write down your own numbers before you read anyone's proposal. Once you've picked a model, data migration testing is what proves it worked. For a second opinion on where the project lands, our data migration services start with the assessment described above.