A public WordPress site can look like ten pages and a contact form. The operational picture may include redirects, form delivery, analytics, embedded services, plugin-generated content, and old URLs that people still use.
If those dependencies are not written down, a clean rebuild can remove something the business relies on. The first migration question is not “Which platform should replace WordPress?” It is “What does this site actually do, and which parts must survive?”
These six facts create a useful starting point. They do not require a redesign brief or a migration estimate.
1. The URLs people and search engines can reach
Start with a list of public URLs. Include pages, posts, landing pages, media files linked from important pages, and URLs reached through the main navigation. Add URLs from the XML sitemap, analytics, Search Console, and any campaign records you still have.
Do not treat the current menu as the complete inventory. A page can be absent from navigation and still receive search traffic, referral traffic, or bookmarked visits.
For each URL, record one intended outcome:
- Keep the same URL.
- Move it to a specific new URL.
- Consolidate it into a relevant page.
- Retire it with a deliberate not-found response.
Google’s current site-move guidance recommends preparing a mapping from old URLs to new destinations and redirecting old URLs to the corresponding new ones. It also warns against sending many unrelated old URLs to the home page.
This is why “we will redirect everything later” is not a migration plan. The mapping is part of the scope.
2. The content you can export, and the content you cannot
WordPress has a built-in export tool. According to the WordPress Tools Export documentation, its WXR file can include posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, and users.
That list is useful because it also shows the boundary. The standard content export is not evidence that you have captured every theme setting, plugin setting, form destination, redirect, reusable layout, or external service connection.
Before planning a move, collect:
- A current WordPress content export.
- A media-library inventory or backup.
- The active theme and child theme, if any.
- Active and inactive plugins with versions.
- Form definitions and confirmed delivery destinations.
- Redirect rules held in WordPress, a plugin, the host, or a proxy.
- Analytics, consent, chat, scheduling, payment, and marketing tags.
The purpose is not to copy every component. It is to separate portable content from behaviour that needs a replacement decision.
3. The administrator evidence behind the public site
A public review can show what a visitor receives. It cannot confirm the whole operating environment.
WordPress provides a useful administrator-side snapshot under Tools, Site Health. The official Site Health documentation says the Info view includes WordPress version, active and inactive themes, active and inactive plugins, media handling, server details, database details, constants, and filesystem permissions.
That snapshot answers several questions that public browsing cannot:
- Which plugins are actually installed?
- Are automatic updates enabled?
- What PHP and database environment supports the site?
- Which inactive themes and plugins remain present?
- Are there critical issues or recommended improvements in Site Health?
If administrator access is not available during an initial fit check, mark those facts Not Verified. Do not infer them from a version scanner or a visible page alone.
4. The public interfaces and private handoffs
WordPress can publish content through more than rendered HTML. The WordPress REST API handbook explains that public content is generally publicly accessible through the API, while private content and restricted fields require authentication.
That makes public API routes, feeds, sitemaps, and embedded files part of the observable site surface. They may also be used by another system.
Forms need a separate handoff check. A public test can show that a form accepts input or displays a confirmation. It does not prove where the message went, whether spam controls ran, whether consent was recorded, or whether a CRM created the right record.
For each form, ask the owner to confirm:
- Who receives the submission?
- What happens if delivery fails?
- Does the submission enter another system?
- What consent and retention rules apply?
- Which test proves the replacement path works?
The same method applies to booking widgets, newsletter forms, file downloads, maps, calculators, and chat tools. Record the public behaviour, then identify the person who can confirm the private handoff.
5. The maintenance and public-exposure baseline
The WordPress project describes security as continuous work. Its hardening guidance says WordPress should be kept current and recommends regular, tested backups. Its broader security guidance also calls for WordPress core, plugins, and themes to be kept up to date.
A migration-fit review should therefore distinguish two questions:
- What does the public site reveal today?
- What can only be confirmed with administrator, hosting, code, or database access?
The first question can produce a public-exposure summary. The second produces a list of evidence gaps. Neither result is a penetration test, formal audit, or statement that the site is secure.
This boundary matters. A short public scan can support a migration decision without pretending to answer questions that require private access.
6. A performance baseline that can be repeated
Take measurements before changing the platform. Otherwise, “the new site feels faster” is not a useful comparison.
Google’s PageSpeed Insights documentation explains that the tool can show both lab data and field data. Lab data is collected in a controlled test and helps diagnose a page. Field data reflects real-user experience from the Chrome User Experience Report when enough data is available. The two can differ.
Choose a small representative set:
- Home page.
- A standard content page.
- A long article or resource page.
- A page with a form or important embed.
- A page with the heaviest media.
Record mobile and desktop results, test conditions, date, and whether field data was available. Google’s current Core Web Vitals guidance measures loading, interactivity, and visual stability through Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift.
The baseline is not a guarantee that another platform will be faster. It is evidence you can repeat after a prototype or migration.
Turn the evidence into one decision
Once the six facts are collected, the next step should be one of three outcomes:
- Proceed to a deeper migration review. The site is a plausible fit, and the remaining questions are bounded.
- Investigate a specific dependency. A form, plugin, redirect set, private workflow, or content type needs proof before anyone estimates the move.
- Keep the current setup. The migration does not yet solve a defined operating problem, or the site’s custom behaviour makes a simple move unrealistic.
That is the purpose of a fit assessment. It should make the decision clearer before design and implementation work begins.
