Key Takeaways:
-
An implementation consultant is not extra capacity. The value is in decisions taken early, not in hours delivered later.
-
The base rates justify the role. McKinsey and Oxford found that large IT projects run 45 % over budget and deliver 56 % less value than predicted. Most of that gap is decided before the first line of code.
-
Most of the work is not development. It is field-level clarification, rule definition, and getting the right people to agree on what a value means.
-
The engagement should be scoped by data complexity, not by headcount. Number of source systems, undocumented fields and approval chains predict effort better than record counts.
-
The deliverable is a repeatable process, not a completed migration. A one-time run leaves nothing behind.
An implementation consultant in a data migration earns their cost in the first three weeks, not the last three. The work is establishing what the data means, which rules may transform it, and who is allowed to approve that. Everything downstream, building the transformations, running them, checking them, is comparatively predictable. Scoping the engagement by developer days therefore prices the smaller and least risky half of the work.
We wrote several proposals this summer where this was the actual point of contention, usually without being said out loud.
What the role is not
It is not a pair of hands added to an existing team to go faster. If the open questions are unresolved, more capacity produces more work built on assumptions that later turn out wrong.
It is also not a hand-over model. An engagement in which an external party takes the system away, migrates it and hands back a result produces exactly one thing reliably: a target system nobody internally can explain.
The research backs the instinct. When Flyvbjerg and Budzier studied 1,471 IT projects, the damage was concentrated in a minority of projects that went badly wrong, one in six with a 200 % cost overrun. What separates those projects is rarely engineering skill. It is unexamined assumptions about scope and data, made early and discovered late. That is exactly the territory this role exists to clear.
What it actually covers
Field-level clarification. Walking the source fields and establishing, for each, what it means, who maintains it, and whether it is still in use. In a grown system a third of the fields typically have no owner. That third is the project.
Rule definition with a justification. For every transformation, one sentence on why. Not in a separate document. Next to the rule. This is what makes the migration defensible two years later.
Approval design. Who signs off on what, based on which artifact. If the answer is "the project manager, based on the log file", the approval is decorative.
Cut-off decisions. What migrates, what gets archived with read access, what is deliberately dropped. All three are legitimate. Not deciding is not.
The rehearsal regime. How often the full path can be run before go-live, and what has to be true for a run to count as passed.
{{feature:onboarding-flow}}
Where the cost actually sits
Effort in a migration correlates poorly with record count and strongly with three other things:
- Number of source systems. Two systems are not twice one. Each additional source adds a reconciliation problem against everything already mapped.
- Undocumented fields. Every field without an owner is a clarification loop through people who have other jobs.
- Length of the approval chain. In regulated settings this dominates everything else.
We scope engagements along these three. It makes proposals less comfortable and projects more predictable.
The delivery shape follows from it
Not every project needs the same depth of support. In practice it falls into three shapes:
Platform and setup, where the customer team runs the migration themselves after an initial configuration. Works when the sources are well understood and documented.
Platform plus migration engineering, where complex or undocumented sources need transformation work that a business team cannot reasonably build.
Platform plus service across several waves, where a large customer base moves in stages and each wave carries its own approval.
The deciding factor is data complexity, not deal size. That distinction matters, because scaling service with every deal is what turns a software business into a body shop.
What should be left behind
The measure of a good engagement is what remains once it ends. A migration that ran once and cannot be repeated leaves nothing. A documented set of rules, a check that runs automatically, and a team that can execute the next wave without us. That is the deliverable.
We build the process so it is repeatable from the first run, and we hand over the operation of it. Not out of modesty. A process only one party can run is a dependency, and dependencies are what customers came to us to get rid of. If you are scoping an implementation right now, start with the field list, not the day rate.
{{cta:onboarding-playbook}}
Sources
- Bloch, Blumberg, Laartz: Delivering large-scale IT projects on time, on budget, and on value, McKinsey & Company / University of Oxford, 2012
- Flyvbjerg, Budzier: Why Your IT Project May Be Riskier Than You Think, Harvard Business Review, September 2011