Blog migration to HubSpot.
Two hundred posts, and every redirect. A blog archive is usually the most valuable organic asset a company owns and the least carefully migrated. Authors, tags, canonical URLs, featured images, paginated archives and every internal link have to arrive intact or the traffic does not.
The posts arrive. The equity does not.
Copy two hundred posts into a new blog and you have two hundred posts. What you may not have is the tag archives that were ranking, the author pages that carried author bios, the internal link graph that distributed authority, and the canonical tags that stopped duplicates competing.
Two hundred posts. Six hundred URLs.
Blog — the archiveA blog is more URLs than it looks.
Archives multiply the URL count
Tag pages, category pages, author pages, date archives and their paginated variants mean a two hundred post blog often has six hundred indexed URLs. Every one needs a rule in the redirect map.
Internal links point at the old site
Posts link to each other by absolute URL. Left alone they resolve through redirects, which works but leaks authority and compounds across hundreds of posts. We rewrite them to the new URLs during the import.
Authors are records, not text
HubSpot blog authors are objects with a bio, avatar and social links, and they have their own listing pages. Importing the author as a string throws away the author page and the structured data attached to it.
Featured images and inline media
Images have to move to the HubSpot file manager and be rewritten inside post bodies. Leaving them on the old host means the day the old host is switched off, every post loses its images.
Canonicals and syndicated posts
Guest posts, syndicated content and anything with a canonical pointing elsewhere need that tag preserved, or duplicates start competing with the original.
Comments and structured data
Comment history and article schema either carry or are consciously dropped. Article structured data in particular is worth rebuilding because it affects how posts appear in results.
The sequence, start to cutover.
Discovery
Object counts, custom fields, automation and the integrations that will break on the way out, read from the source system rather than from a questionnaire.
Mapping
Field by field, including what will not carry across, agreed and signed before anyone exports anything.
Dry run
A complete rehearsal into a sandbox portal, reconciled against source counts so the gaps surface a month early rather than on cutover night.
Automation rebuild
Workflows, sequences and routing rebuilt to the new model rather than transliterated from the old one, which is how a migration inherits a decade of workarounds nobody remembers writing.
Cutover
A dated switch with the legacy system read-only for a defined window, and a rollback that was tested rather than assumed.
Post-migration support
A named engineer through the first full reporting cycle, which is when the questions actually arrive.
Nobody crawled the old site.
You cannot build a complete redirect map from a list of post titles. We crawl the live blog first, take the URL inventory from what is actually indexed, and diff it against the new site after launch. Every URL that lost a destination, a title or a canonical appears on a list rather than in a traffic report a month later.
What people ask before they commit.
Will we keep our blog rankings?
If the redirects are complete, the metadata carries and the internal links are rewritten, yes. A few weeks of volatility is normal. A sustained drop is nearly always a missing redirect rule on an archive pattern.
Can you migrate from WordPress, Webflow, Ghost or Medium?
Yes. The source matters less than whether we can get at the full post bodies, the metadata and the URL inventory. Medium and other hosted platforms need more care because the export is thinner.
What happens to our tag and category pages?
They become HubSpot blog tags with listing pages. Where the old structure had both tags and categories doing overlapping jobs, we consolidate and redirect rather than reproducing the duplication.
How long does a blog migration take?
Two to six weeks depending on post count and how much of the content needs its markup cleaned on the way through. Older blogs carry a lot of inline styling that is worth stripping.
Should we migrate every post?
No. Most blogs have a long tail with no traffic, no links and no relevance. We take the inventory, and posts with nothing to lose either get consolidated into stronger pages or retired with a redirect.
Where people go from here.
Move the archive. Keep the equity.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.