Most WordPress-to-HubSpot migrations fail not because HubSpot is the wrong platform, but because teams treat the move like a site rebuild when it's actually a RevOps re-platforming. Here is the 6-phase playbook we use on client engagements, with realistic week-by-week timelines and the specific failure modes to plan for at each phase.
Phase 1: Audit + scoping (weeks 1-2)
Before anything technical happens, inventory every page, form, plugin, and integration. Categorize each one against a migration matrix: (a) keep and refactor into HubSpot, (b) retire entirely, (c) replace with a native HubSpot feature, (d) requires custom development.
The output of this phase is a migration matrix that drives every decision downstream. Don't migrate pages you're about to kill anyway — use the migration as a pruning exercise. A typical audit surfaces 20-40% of pages that nobody's looked at in 18+ months and no longer serve a purpose.
Critical artifact: document current URL patterns before touching anything. You will need them for 301 redirects. This is the #1 source of post-launch SEO issues.
Phase 2: Information architecture + content model (weeks 2-3)
Design the HubSpot templates, modules, and HubDB schemas around the new IA, not the old one. If you rebuild the same mess on a new platform, you've done a lift-and-shift, not a migration — and you've paid for the privilege of shipping it twice.
Decide on URL patterns up front. The migration is the cheapest time to fix bad URL patterns — every month after launch, the cost compounds through internal links, external backlinks, and cached search results.
Rule of thumb: cap template count at 8-12. Module proliferation is the #1 cause of post-launch maintenance pain. A disciplined module library is worth more than feature coverage.
Phase 3: Template + module build (weeks 3-5)
Build templates in HubSpot's design manager or via the CLI (we prefer the CLI for version control and code review). Each module gets field-level validation, clear authoring affordances, and documentation for content editors.
This is where custom dev enters if HubSpot's native capabilities fall short: Projects (serverless functions) for server-side logic, custom modules for reusable UI blocks with typed fields, HubDB for structured data that drives dynamic pages.
Run design QA with a content editor, not just a developer. The failure mode here is building modules that technically work but have bad authoring ergonomics, forcing the marketing team to learn developer concepts they shouldn't have to.
Phase 4: Content migration (weeks 4-6)
Export WordPress content via WP-CLI or the REST API. Transform into HubSpot's structure — body HTML, image paths, metadata. Media assets route through HubSpot's file manager.
For 500+ pages, a scripted migration is mandatory. For <100 pages, manual import is often faster than scripting and produces cleaner results. Somewhere between 100-500, it depends on how consistent your WordPress content structure is.
Non-negotiable gate: never migrate content without validating every internal link works in the new environment first. Broken internal links are an SEO liability and a user-trust liability. An automated link-checker run against the staging environment should pass before cutover is even scheduled.
Phase 5: Forms, integrations, attribution (weeks 5-7)
Rebuild forms in HubSpot. This is where the RevOps payoff starts to show up — HubSpot forms natively capture UTM, gclid, fbclid, page URL, and session context, and push everything into the contact record without the stitching that WordPress forms require.
Wire CRM objects, sequences, workflows, and external integrations (Salesforce, NetSuite, custom APIs, data warehouse exports). Validate attribution end-to-end: UTM capture, first-touch, last-touch, form-submit fire-through to the deal pipeline.
Test lifecycle-stage transitions explicitly. A common failure mode is that leads convert into the CRM but don't progress through lifecycle stages correctly, leaving sales staring at a pipeline that doesn't match marketing's reality.
Phase 6: Cutover + 301 redirects (weeks 7-8)
Switch DNS on a Friday afternoon and watch the weekend. Every old URL gets a 301 redirect to its new location. Monitor Google Search Console for 404s daily for the first 30 days; set up a Slack alert if 404 count spikes above a reasonable baseline.
Realistic expectation setting:plan for a 10-20% temporary organic traffic dip in weeks 2-4. Full recovery by week 10-12 is the realistic target. Stakeholders who aren't warned in advance of this pattern often panic around week 2 and demand rollbacks that would make things worse.
Cutover discipline: stage a parallel run with a test domain for the final week. Do not cut over on a Monday morning. Pre-warm the HubSpot CDN by hitting the top 200 URLs in the 24 hours before DNS flip.
Total timeline: 7-9 weeks
For a typical mid-market site (50-150 pages, 15-30 forms, 2-3 integrations, light custom dev), the compressed timeline is 7 weeks; the comfortable timeline is 9. Add 2-3 weeks if you have heavy custom CRM objects, Salesforce sync, or a complex locale structure.
Anything under 6 weeks is almost always a lift-and-shift that will need a follow-up engagement to clean up. Anything over 12 weeks usually indicates scope that should have been descoped during Phase 1.
What's next
This playbook covers the operational sequence. The complementary question — when to build custom on top of HubSpot vs. accept native limitations — is covered in our custom extensions on HubSpot article. For the full scoping framework, including budget templates and the migration matrix, the free migration guide is the deepest version of this content.