The In-House CMS Migration Cost Model: Four Line Items Missing From the Comparison
The spreadsheet almost always looks the same. Agency proposal in one column, four internal engineers and a content lead in the other, twelve months across the top. The internal column comes out lower, someone circles it, and the decision is made in a forty-minute meeting. Nine months later that team is explaining why the migration sits at sixty percent and the Q3 roadmap has not moved since February.
The in-house CMS migration cost in that comparison is understated, and not because anyone was dishonest. eight25 is a Silver-tier Contentful Solution Partner and Contentstack Preferred Partner, with enterprise migration experience across platforms including Sitecore, Tridion and Contentstack/Contentful estates.
The in-house CMS migration cost comparison is missing four line items
In-house can look cheaper because the comparison usually gives the most attention to the easiest category to quantify: direct cash cost. As migration complexity increases, the categories it leaves out fully loaded internal capacity, deferred roadmap work, elapsed time, and delivery risk can materially change the answer, and in some enterprise migrations they outweigh the implementation fee itself.
A model that compares agency fees to internal salaries is a cash-flow projection wearing a cost model’s clothes. It answers “which invoice is smaller,” which nobody actually needs to know, instead of what it would cost to get this estate onto the new platform by a date you can defend, with a team that can run it once you get there.
Five categories make up that total, and this is where in-house vs agency CMS migration decisions go wrong: most in-house cases are built on the first one alone.
| Cost category | On the typical spreadsheet? | Usually larger or smaller than expected |
|---|---|---|
| Direct cash cost agency fees or allocated internal labor | Yes | The easiest category to see and compare |
| Fully loaded internal labor adjustment | Inconsistently | Salary alone excludes benefits, payroll costs and other employer costs |
| Deferred roadmap / opportunity cost | Rarely | Can become one of the largest economic costs when high-value work is delayed |
| Elapsed-time cost | Rarely | Extends legacy-platform cost, internal effort and delayed value |
| Risk-adjusted delivery cost | Rarely | Accounts for the probability and consequence of delay, rework or recovery |
Working through the four missing categories does not always point at an agency. On genuinely simple estates it points the other way, and it points there with more confidence than a cash comparison ever could. What it does reliably is stop the decision from being made on the one number that matters least.
Internal engineers are not free, and they are not available
Two separate errors can hide inside the internal column, and the first is pricing. Base salary is not the same as total employer cost. Benefits, payroll taxes, paid leave and other compensation costs materially increase the figure before equipment and corporate overhead are considered. U.S. Bureau of Labor Statistics data, for example, put average private-industry compensation at roughly 1.43 times wages in March 2026. Your finance team’s burden rate is the right number to use, but comparing an agency’s fully loaded rate with raw employee salary compares two different units.
The second error is volume. Nobody in the internal column is idle, so a migration borrows a team rather than creating one, and the size of that loan almost never gets measured before the decision gets made.
Before pricing anything, inventory the work in FTE-months. CMS migration staffing is not a headcount question and not a calendar-duration question, and only FTE-months by workstream give you a figure comparable across both options.
| Workstream | Planning range (FTE-months) | Peaks when | Specialist skill required |
|---|---|---|---|
| Strategy and discovery | 1–3 | Weeks 1–8 | Content architecture, governance design |
| Content modeling | 2–5 | Weeks 4–16 | Recent hands-on platform experience |
| Implementation and front-end build | 6–24 | Weeks 8–36 | Platform SDKs, framework, migration tooling |
| Integration rebuild | 2–12 | Weeks 12–32 | Per-system: CRM, analytics, search, identity, MAP |
| Content cleanup and entry | 3–15 | Weeks 16–40 | Editorial, plus translation supply chain |
| SEO continuity | 1–3 | Weeks 20–launch, plus 90 days after | Technical SEO at migration scale |
| QA and accessibility | 2–6 | Weeks 28–launch | Automated and manual, WCAG 2.2 AA |
| Training and post-launch ownership | 1–4 | Launch minus 6 weeks, through day 90 | Enablement, not documentation |
This distinction matters even more in a headless or composable migration. Moving from a traditional CMS to an API-first platform such as Contentful or Contentstack is not simply a content transfer. The program typically includes content-model redesign, front-end architecture, API and integration work, migration tooling, governance, and editorial enablement as separate but overlapping workstreams. That creates more architectural freedom after launch, but it also makes recent platform experience disproportionately valuable during the migration itself.
Deferred roadmap is usually the largest number on the page
This is the line item that decides the answer and the one nobody prices. Four engineers on a nine-month migration do not cost you their salaries, which you were paying anyway. They cost you nine months of product and marketing work that never shipped.
Most digital leaders can get within range of this number using initiatives already on the roadmap. Identify the work those engineers would otherwise have shipped, estimate the incremental value attributable to that work, and adjust for the probability and duration of delay. Revenue or pipeline forecasts can be useful inputs, but they should not be treated as dollar-for-dollar losses. On roadmap-heavy enterprise teams, this opportunity cost can become comparable to or larger than the implementation fee itself.
Then there is concentration risk, which is harder to model. Long migrations can place disproportionate dependency on a small number of engineers who understand the legacy CMS, integration layer, or content model. If one of those people changes roles or leaves during the project, replacement and knowledge-transfer costs can arrive at exactly the point where the schedule is least able to absorb them.
If the roadmap for the next two quarters is genuinely thin, or the team is between major initiatives, this whole line item collapses toward zero and the in-house case gets substantially stronger. That happens, and it is worth checking rather than assuming. It is just less common than the spreadsheet implies.
Elapsed time is a multiplier, not a line item
Every additional month a migration runs can extend internal project effort, legacy-platform licensing and hosting, and the business constraints that triggered the migration in the first place. Duration therefore amplifies several other cost categories rather than behaving like a simple standalone expense. A fixed-fee implementation can transfer some delivery-overrun risk to the partner, but the client still carries the business cost of a delayed launch which is why confidence in the schedule matters as much as the quoted fee.
In-house migrations can run longer for structural reasons rather than talent reasons. The risk rises when the same team is splitting attention with business-as-usual work, when nobody has recent experience on the target platform, or when migration work repeatedly loses priority to production demands. A dedicated migration team removes some of those constraints by preserving continuity across discovery, architecture, implementation and launch. For a sense of what dedicated capacity can buy, Qlik moved roughly 5,000 pages from Sitecore XP to Contentful across a global estate in about five months. Discovery, component auditing, build and migration ran as coordinated parallel workstreams rather than a sequence of disconnected phases. Total effort was never the constraint on that schedule. Continuity was. An agency’s schedule advantage comes from that continuity and from the pattern recognition to skip decisions your team would otherwise make twice, not from having better engineers.
This is also where external deadlines become decisive. A migration anchored to a license renewal, an end-of-life notice, or an acquisition close has a date that does not move. In our experience external deadlines kill in-house migrations more reliably than any other single factor, because the one lever an in-house team has when it falls behind is time, and that lever has been removed.
The most expensive outcome is stopping halfway
The most expensive failure mode is often not a project that fails immediately. It is a migration that gets far enough for substantial cost to be sunk before specialist gaps, integration issues or launch-readiness problems become critical. At that point the organization has paid for much of the original migration but may still need additional expertise to get the program across the line.
This is a recurring pattern in recovery engagements eight25 is called into. Recovery can cost materially more than planned implementation because the incoming team first has to understand and validate decisions already made, resolve or work around accumulated technical debt, and deliver against a timeline that has already compressed. Those costs did not exist in the original plan. The incoming team has to understand and validate decisions already made, work around accumulated technical debt, and deliver inside a compressed timeline. All three add cost, and none of them existed in the original proposal. Bring in a partner when you are several weeks behind plan, not in month eight when launch is at risk.
That means the comparison should account for execution risk rather than assuming a best-case delivery plan. As a practical planning heuristic — not a statistically validated risk model — eight25 scores seven signals that have repeatedly increased delivery complexity in the enterprise migrations we have led:
| Complexity score | Lowest-risk staffing model | What the cost model usually shows |
|---|---|---|
| 0–10 | In-house viable if platform experience and roadmap capacity are present | In-house may retain a total-cost advantage |
| 11–20 | Hybrid: partner-led, in-house embedded | Partner cost becomes easier to justify once capacity and schedule risk are included |
| 21+ | Partner-led implementation | Execution risk can outweigh the apparent in-house cash saving |
This is a planning tool developed from migrations we have led and recovered, not a scientific model. Its value is that it forces the conversation to happen before staffing rather than in month six.
Where in-house genuinely wins on total cost
The strongest in-house case tends to be a relatively simple estate: one brand, limited localization, modest content volume, a small and familiar integration footprint, recent hands-on experience with the target platform, documented editorial governance, sufficient roadmap capacity, and a launch date with some flexibility. The more of those conditions that disappear, the more important dedicated migration capacity and specialist platform experience become.
Miss two or more of those and the cash saving in the internal column is usually borrowed against one of the four categories above.
The middle band is where the hybrid earns its place, and it works as a deliberate division rather than a fifty-fifty split. Agency leads discovery, content modeling, governance design, migration tooling, integration architecture, and the front-end build. In-house leads stakeholder management, editorial readiness, content cleanup, post-launch operations, and the ongoing platform roadmap. Integration testing, training, and launch readiness are jointly owned. On eight25’s NetApp migration from Tridion to Contentstack, a roughly 14,000-page, 10-language estate used formal co-development rather than a handoff model. That arrangement was formal co-development: NetApp’s own developers ran their own GitHub repositories, branches, and Vercel environments for the areas they would own long-term, including Account Home, Events, personalization, and account login, and submitted pull requests into our staging branch. That structure is a cost decision as much as a capability one. Internal capacity goes to the work that transfers ownership, and the work an experienced pod simply does faster goes to the pod.
Frequently Asked Questions
Is it cheaper to migrate our CMS in-house?
On direct implementation spend, in-house can look cheaper because there is no agency fee. Total cost is less predictable. A useful comparison should include fully loaded internal labor, deferred roadmap work, elapsed-time cost and delivery risk alongside direct spend. As the estate becomes more complex particularly across multiple locales, integrations or a new headless architecture those additional categories can materially narrow or reverse the apparent in-house saving.
How do I calculate the opportunity cost of an in-house CMS migration?
Identify the people the migration would consume and the initiatives they would otherwise be delivering. Estimate the incremental economic value associated with those initiatives, then adjust that value for the probability and duration of delay. Pipeline and revenue forecasts can inform the estimate, but they should not automatically be treated as fully lost revenue. Add any incremental hiring, contractor, retention or knowledge-transfer cost created by the migration.
How many people does a CMS migration actually need?
Fewer people than the FTE-month total suggests, but more distinct skill sets than most teams have available at once. Inventory the work by workstream in FTE-months rather than by headcount: strategy, content modeling, implementation, integration rebuild, content cleanup, SEO continuity, QA, and training. The binding constraint is rarely total effort. It is that implementation, content entry, and QA peak in overlapping windows and need different specialists.
What does it cost to bring in an agency to rescue a stalled migration?
More than engaging one at the start, because the incoming team pays for three things that did not exist in the original scope: understanding and validating decisions already made, resolving accumulated technical debt, and delivering inside a compressed timeline. The practical guidance is to bring in help when you are several weeks behind plan, while the schedule can still absorb it, rather than when the launch date is already at risk.
How do I find a good CMS implementation partner?
Ask what they would advise you to keep in-house, and treat a partner who has no answer as a warning. Ask what went wrong on their last three migrations and what changed as a result. Ask who owns the platform on day 31 and how the in-house team gets embedded during the build rather than trained at the end. A partner scoping for total cost rather than maximum scope will tell you when in-house is the right call, and will have a defensible reason when it is not.
Before You Staff It, Price It
If your team is weighing in-house delivery against a migration partner, the useful next step is not another generic proposal. It is a scoping exercise that maps the estate by content, integrations, specialist skills, FTE-months and delivery risk then identifies what should stay with your team. At eight25, our CMS discovery work combines content modeling, architecture, governance and migration planning, with particular experience in enterprise headless platforms including Contentful and Contentstack. The goal is not to maximize agency scope. It is to make the ownership model explicit before the migration starts.