Start with scope, not page count
Count published posts, authors, labels, comments, and discoverable inline assets separately. Record the Blogger hostname, custom domain, URL variants, feeds, destination model, and records that need a private or export-based source path.
A small publication with irregular HTML, inaccessible media, several URL families, or an unfinished WordPress destination can require more work than a larger consistent archive.
Separate five cost workstreams
| Workstream | Typical scope | Cost driver |
|---|---|---|
| Content migration | Posts, authors, labels, comments, dates, HTML, assets | Volume, relationships, access, exceptions |
| SEO and redirects | URLs, metadata, links, sitemap, launch checks | Hostname control and path variants |
| WordPress implementation | Types, taxonomies, users, fields, templates, plugins | Destination readiness and development |
| Feeds and subscribers | RSS, Atom, FeedBurner, email systems | Separate services, ownership, permissions |
| Ongoing ownership | Hosting, updates, backups, security, performance | Operational work after migration |
Identify the main Blogger cost drivers
Cost changes with archive size, comment volume and parentage, label mapping, inline image discovery, external or missing files, multiple blogs, URL variants, custom domains, private or draft content, and destination preparation.
Other drivers include embeds, inconsistent HTML, duplicate slugs, missing authors, feed continuity, active publishing, dry runs, delta migration, evidence requirements, and support.
Use packages as starting points for fit
Launch can fit a supported straightforward migration with a prepared destination and limited records. Growth can fit an archive with media, taxonomies, SEO metadata, preserved slugs, and redirects. Scale can fit higher volume, custom fields, advanced relationships, extra dry runs, reconciliation, and delta cutover. Custom covers unsupported access, adapters, application work, or larger scope.
These are fit signals, not guarantees. Confirm current terms in the pricing overview and application estimate.
Bring enough information for a useful estimate
Provide the public blog URL, custom-domain details, export availability, counts by record type, sample posts, comment volume, label structure, inline image behavior, feed endpoints, WordPress status, permalink preference, launch window, and support expectations.
Flag drafts, private posts, standalone pages, deleted content, multiple blogs, external media, newsletter tools, and third-party records. The public Blogger path should not be assumed to expose them.
Know the exclusions
Blogger themes, widgets, gadgets, forms, custom scripts, subscriptions, email systems, Google credentials, paid services, and unsupported records do not become WordPress equivalents through content migration. Theme and application reconstruction need separate work.
The import guide explains record boundaries. The redirect and SEO guide covers URL, metadata, feed, and monitoring work.
Reduce avoidable work before import
Approve the WordPress model and permalink strategy, create a dated backup, inventory the live site, identify owners, document external assets, choose label mappings, and prepare staging access.
Do not delete the source or release the custom domain. A stable baseline and rollback option reduce uncertainty during validation and cutover.
Calculate the scope in the app
Review broader CMS migration cost factors, the Blogger vs WordPress comparison, and current compatibility.
Use the application estimate for known volume and options. Treat it as a starting estimate until access, destination readiness, exceptions, URL work, and acceptance requirements are confirmed.