In-House vs. Agency CMS Migration: When Each Actually Wins

The CFO is staring at two numbers. One is an agency proposal to migrate the marketing site off the legacy CMS. The other is the fully loaded cost of the in-house team that’s already on payroll. The arithmetic looks obvious on the spreadsheet, and the question lands in your inbox: “Why are we paying an agency when we have engineers?”

That conversation is happening in marketing leadership meetings across mid-size and enterprise B2B companies right now and in our experience recovering stalled migrations, the cost-only view is the single most common root cause of the failures we’re brought in to fix.

Based on the enterprise CMS migrations we’ve led, for organizations including NetApp, Sophos, and Ellucian, organizations with higher migration complexity (multi-brand sites, multi-locale publishing, large content volumes, or a hard launch date) often reduce implementation risk and avoid costly delays by working with an experienced implementation partner. eight25 is a certified Contentful and Contentstack partner. The exception is a narrow set of scenarios where in-house genuinely wins.

This guide is the framework we use with marketing and digital leaders to figure out which case they’re in, before they sign anything, and before they staff anything.

The Decision That Gets Made on the Wrong Inputs

Most teams approach this decision as a cost comparison. They build a spreadsheet that puts internal engineering hours next to an agency SOW, conclude the agency is “more expensive,” and move forward with in-house, or they panic at the scope of the work, hand the whole thing to an agency without understanding what to keep, and lose institutional knowledge in the process. Both versions of the mistake share a root cause: the inputs are wrong.

The cost of a CMS migration isn’t dollars. It’s elapsed time, team focus, governance risk, and what gets dropped from the marketing roadmap to make room for it.

One of the most common budgeting mistakes is comparing agency fees against internal salaries. Internal teams are not free. The real comparison is agency cost versus the value of the roadmap work that won’t ship while senior engineers, architects, and marketing operations teams are focused on migration activities. For many organizations, that opportunity cost exceeds the implementation fee itself.

Dimension	In-House Team	Agency
Domain knowledge	Deep – knows the legacy system, editorial pain points, integrations	Shallow at kickoff; recovered through structured discovery
Platform breadth	Usually deep on one platform; thin across the market	Multi-platform comparison data from recent enterprise implementations
Cost profile	Already on payroll; high opportunity cost against the roadmap	Higher cash cost; predictable scope, no internal opportunity cost
Capacity at scale	Limited by team size and competing priorities	Dedicated pod for the project duration with no staffing gaps
Governance design	Often deferred or built bottom-up after launch	Designed up front in discovery, validated in staging
Risk concentration	One or two key people carry tribal knowledge	Distributed across an experienced pod with proven patterns
Post-launch operations	Strong – team owns the platform from day one	Strong when ownership transfer is designed in (training, docs, runbooks)
Vendor commercial leverage	First-time buyer pricing	Partner-tier discounts and licensing negotiation experience

In-house wins on day-one domain knowledge and post-launch operations. An agency wins on the categories that decide whether the migration finishes on time, on budget, and on a foundation the team can actually run. Experienced implementation partners often have an advantage in the categories most closely tied to delivery predictability: dedicated capacity, migration tooling, governance design, and recent platform experience.

The eight25 CMS Migration Complexity Framework

Rather than asking “which is cheaper,” score the migration’s complexity first. We use seven factors (this framework isn’t intended as a scientific model. It’s a practical planning tool developed from enterprise migrations we’ve led and recovered). Most are directional rather than absolute, a 300-page site with ten integrations can be harder than a 5,000-page brochureware site, but together they reliably predict where a migration will strain an internal team.

Factor	Low	Medium	High
Page count	< 500	500–2,000	2,000+
Brands	1	2–3	4+
Locales	1	2–5	6+
Integrations	1–5	6–10	10+
Compliance	Minimal	Moderate	High (regulated)
Governance maturity	Documented	Partial	Undefined
Timeline	Flexible	Moderate	Fixed / external

Migration Complexity Score

Score each factor that applies, then total:

Signal	Points
Multi-brand	5
Multi-locale	5
1,000–5,000 pages	5
5,000+ pages	10
Custom integrations beyond the basics	5
Compliance / regulated governance required	5
Hard external deadline	5

• 0–10 → In-house is viable if platform experience and roadmap capacity are also in place.
• 11–20 → Hybrid (agency-led, in-house embedded) is usually the lowest-risk path.
• 21+ → Agency-led implementation is strongly recommended.

eight25 Observation: Integration complexity is often a stronger predictor of migration risk than page count. Teams routinely estimate migration effort from content volume while underestimating the time required to rebuild CRM, analytics, search, identity, and marketing-automation integrations. A modest-content site with a dozen live integrations is frequently the harder project.

Disclaimer: This framework isn’t intended as a scientific model. It’s a practical planning tool developed from enterprise migrations we’ve led and recovered.

What a CMS Migration Actually Involves

Before answering the in-house vs. agency question, get a realistic picture of the work. Most teams scope a migration as “move the content and rebuild the templates” and budget accordingly. The actual workstreams are wider and the underestimation is where projects go off the rails, almost always inside the in-house team’s first 90 days.

A typical enterprise CMS migration involves six parallel workstreams:

1. Content modeling – Redesigning content types, fields, and relationships for the new platform’s architecture. Rarely a one-to-one map from the legacy model.
2. Content migration – Extracting, transforming, and loading content, including rich-text components, embedded assets, reference repair, and URL preservation for SEO.
3. Integration rebuilding – Reconnecting CRM, marketing automation, search, analytics, personalization, and custom services that touched the legacy CMS.
4. Front-end implementation – Templates, components, design-system integration, and accessibility compliance on the new platform.
5. Governance and editorial workflow – Role permissions, environment promotion, approval chains, and editorial UX configuration.
6. Training and ownership transfer – Editor enablement, developer documentation, runbooks, and the post-launch support window.

Each workstream has its own staffing curve, peak intensity, and risk profile. An in-house team built for ongoing platform operations is rarely staffed for the simultaneous peak of all six. An agency pod is.

When an Agency Actually Wins

These are the patterns where in-house attempts fail more often than they succeed, and where the cost of failure is well above the cost of the agency.

• Multi-brand or multi-locale architecture. Several brands sharing a content model, or many locales with locale-specific publishing schedules, is governance work that gets harder, not easier, as you scale. Agencies that have built this before often bring proven governance and content-modeling patterns. Internal teams may need to develop and validate those approaches during the migration itself, which can increase delivery risk.
• Large page counts with active editorial. Content migration at scale is automation work: rich-text component extraction, broken-reference repair, redirect mapping, version-history decisions. Building that tooling for a one-time event isn’t a good use of internal engineering capacity.
• A high integration count being rebuilt. Reconnecting CRM, MAP, CDP, search, personalization, analytics, and SSO at once touches systems most in-house teams have never had to redesign simultaneously. The integration architecture is where multi-month delays compound silently. (See the integration tiers in the complexity framework above.)
• A launch date that can’t move. Renewal cliffs, EOL deadlines, and acquisition integrations come with hard dates. When deadlines are fixed, agencies can often add specialized resources, migration engineers, QA specialists, and implementation leads, without requiring the client to pause other roadmap initiatives.
• Compliance or security requires a designed governance model. Financial services, healthcare, and higher-education buyers need a role matrix, environment-promotion flow, and audit trail designed before launch, not patched in afterward.
• The team has no recent experience with the target platform. Learning Contentful, Contentstack, or Optimizely while simultaneously running a production migration can significantly increase delivery risk and timeline uncertainty.
• The marketing roadmap can’t absorb a six-month focus shift. If pulling the team off feature work creates a year of catch-up, the apparent savings of in-house disappear inside opportunity cost.

Migration Ownership Matrix

Characteristic	In-House	Hybrid	Agency
Under 500 pages	✓
500–2,000 pages		✓
2,000+ pages			✓
Multi-brand / multi-locale		✓	✓
Compliance-heavy			✓
Hard external deadline			✓
Existing target-platform expertise	✓	✓

What we see on complex implementations is that in-house teams attempting to absorb all of this tend to complete the majority of the work, hit a wall partway through, and bring in an agency anyway, usually under more time pressure and at higher cost than the original proposal. Recovery engagements are often more expensive than engaging a partner earlier because the incoming team must first understand and validate decisions already made, address technical debt accumulated during the project, and work within a compressed timeline.

When In-House Actually Wins

There are migrations where bringing in an agency is overhead. In-house can be the right choice, but typically only when migration complexity, integration requirements, and organizational constraints are all relatively low. In-house wins when all of these are true at once:

• The site is single-brand, single-locale, and roughly under 100 pages. Content volume that fits inside one quarter of focused engineering work is tractable for an internal team.
• The team has hands-on experience with the target platform from a recent project. Engineers who’ve shipped on Contentful or Contentstack move far faster than engineers learning the platform alongside the migration.
• The integration footprint is small. Two or three integrations the team already maintains is manageable. Anything wider has to be re-architected and that’s an agency conversation.
• The roadmap can absorb a six-month focus shift without breaking other commitments.
• Editorial governance is already mature. Teams already running a clean editorial workflow can usually replicate it. “Slack approvals and hope” will not become a governance model under migration pressure.
• The launch date is internally chosen and can move. External deadlines kill in-house migrations more reliably than any other factor.

If several of these conditions aren’t true, the in-house business case becomes harder to justify and a hybrid or agency-led approach deserves serious consideration. The biggest hidden cost of an in-house migration isn’t the build, it’s the velocity lost on everything else the team would have shipped.

The Hybrid Model: Agency-Led, In-House Embedded

Most enterprise migrations are best run as a hybrid, where the agency leads the build and the in-house team is embedded inside it. This isn’t a 50/50 split, it’s a deliberate division of labor designed in discovery.

• Agency leads: discovery, content modeling, governance design, migration tooling, integration architecture, the front-end build, and training-program design.
• In-house leads: stakeholder management, editorial readiness, content cleanup and prep, post-launch operations, and the ongoing platform roadmap.
• Joint ownership: integration testing, training execution, and the launch-readiness review.

The discipline this requires is honest scoping. You get the benefit of a hybrid when both sides agree on which workstreams sit where, document the handoffs, and run weekly check-ins where both engineering leads are accountable. This is also the model where ownership transfer actually works: the in-house team has been embedded throughout, not handed a runbook on launch day.

Common CMS Migration Failure Patterns

Across the migrations we’re brought in to lead, and the stalled ones we brought in to recover, the same failure patterns recur:

1. Content cleanup is underestimated. Teams budget to move content, not to audit, deduplicate, and retire it first.
2. Integrations are rebuilt later than planned. Integration work is sequenced after the front end, then becomes the critical path.
3. Governance is defined after implementation begins. Role matrices and approval flows get retrofitted, often after a failed audit.
4. Training is treated as a launch-week activity rather than a workstream that runs throughout the build.
5. Legacy content models are copied instead of redesigned, carrying old constraints onto the new platform.
6. Post-launch ownership is never assigned, so the platform drifts once the project team rotates off.

CMS Migration Readiness Checklist

Use this before requesting agency proposals or committing to an in-house build.

Content

• Inventory all content types and templates
• Identify obsolete or redundant content to retire
• Create a redirect / URL-preservation strategy for SEO

Technology

• Document every integration touching the current CMS
• Define authentication and SSO requirements
• Define performance and Core Web Vitals targets

Governance

• Document editorial roles and permissions
• Define approval workflows and environment promotion
• Assign publishing responsibilities

Operations

• Name the day-31 platform owner
• Build a training plan into the timeline (not launch week)
• Define a first-90-day post-launch support model

Questions to Ask Before You Decide

Work through these with your engineering and marketing leads in the same room:

1. What’s the realistic page, locale, and integration count after a clean content audit?
2. Has anyone in-house built on the target platform in the last three years?
3. What roadmap initiatives will be deferred if the team owns this end-to-end and what’s the dollar impact?
4. Is the launch date externally driven (renewal, EOL, acquisition) or internally chosen?
5. What does current editorial governance look like, and is it documented?
6. Who owns the platform on day 31 after launch, and have they been embedded in the build?
7. If the migration runs three months over, what breaks and is that acceptable?

One practical capacity test: if the team that already handles business-as-usual website operations has limited available capacity, delivering a complex migration without affecting roadmap commitments becomes significantly more challenging.

Key Takeaways

• Migration complexity and the delivery model chosen predicts success better than implementation cost.
• Integration complexity is often a bigger risk than page count.
• Governance should be designed before implementation, not after a failed audit.
• A hybrid (agency-led, in-house embedded) model fits most enterprise migrations.
• Post-launch ownership must be assigned before launch, not on launch day.

Frequently Asked Questions

Planning a CMS Migration?

If your team is in the early scoping phase, the most valuable conversation you can have before requesting proposals is an honest scoping discussion that maps the real workstreams against your team’s current capacity. eight25 runs a focused discovery sprint that produces an architecture recommendation, content model, governance design, and a realistic timeline, including which parts of the migration we’d recommend you keep in-house. The goal is the right answer for your team, not a maximum-scope SOW.

Start a conversation with our team

eight25 CMS Migration Services