How to Migrate a Drupal Website to WordPress with a Freelancer

How to Migrate a Drupal Website to WordPress With a Freelancer: A Content and Feature Transition Plan

A Drupal-to-WordPress migration is not just a transfer of pages. Drupal sites often rely on content types, taxonomies, fields, permissions, and modules that do not have direct WordPress equivalents. If those details are missed, the new site may look finished while search filters fail, author credits disappear, or media files become detached from their content.

A freelancer can manage the work, but the project needs clear decisions from the site owner as well. Before asking how to migrate a website from Drupal to WordPress with a freelancer, gather a content inventory, identify the features people actually use, and agree how the two systems should differ after launch. That gives the migration a testable plan rather than a vague instruction to “move everything.”

1. Map Drupal content types to WordPress structures

Start by listing Drupal content types and the fields attached to each one. A news article might contain a title, summary, body, author, publication date, topic, and hero image. A product page may have a different set of fields and a relationship to a category or supplier. The freelancer needs this inventory before choosing WordPress structures.

Drupal nodes may map to standard WordPress posts or pages, but some content deserves a custom post type. For example, an organization directory with its own archive and profile fields is usually clearer as an “Organization” post type than as a collection of ordinary pages. Taxonomies may become WordPress categories or custom taxonomies, depending on how they are used. A field-by-field mapping table makes those decisions visible.

Do not assume that matching field names means matching behavior. A Drupal field that allows several values may need a different WordPress setup from a field that stores one value, and a date stored with a timezone may require an explicit conversion rule. Record examples of unusual values so the freelancer can test them rather than guess.

Keep URLs in the mapping too. If a Drupal article currently lives at /news/community-update, decide whether WordPress will preserve that path or redirect it to a new one. A mapping spreadsheet with source content type, destination structure, fields, taxonomy rules, and URL treatment gives both sides a reference during testing.

2. Decide what to rebuild, replace, or leave behind

Drupal modules often support a specific workflow, and copying the visible feature is not enough if the workflow behind it matters. List the modules and custom functions the site currently uses, then note who depends on each one. A member login, an editorial approval queue, and a faceted search may call for three different WordPress solutions.

Sort each item into one of three groups: rebuild in WordPress, replace with an available tool, or leave behind. For instance, an old event calendar with no upcoming events might not need to move at all. A public directory that still receives daily use may need a replacement with searchable fields. A custom approval process may require development if the new editorial setup cannot reproduce its required steps.

Ask the freelancer to describe the proposed solution and its limits for every feature that will remain. If a replacement changes who can edit content or how a visitor finds it, document that change before the build starts. “Works like Drupal” is not a useful acceptance test; “editors can submit an article for review without publishing it” is.

Separate essential functions from preferences. This helps control scope when a Drupal module has no direct counterpart, and it gives the owner a chance to approve a simpler process. For broader questions about choosing an individual contractor or a team, see should i hire a freelancer.

3. Prepare a representative migration sample

Before moving the entire database, ask the freelancer to migrate a small sample that includes different content shapes. A basic page tests simple fields and URLs. A taxonomy-heavy article tests term assignments and hierarchy. A media-rich item tests image files, captions, and embedded content. If the site has a special content type, include at least one example of it.

The sample should be large enough to expose different cases, but small enough for the owner or editor to review record by record. Agree on which source items to use and what “correct” means for each one. For example, the article sample may need its original author, two topic terms, an updated date, and a downloadable attachment.

Review the WordPress result against Drupal, not just against a design mock-up. Check whether the content is editable, whether taxonomy filters return the expected items, and whether media appears in the right place. A page can look fine while its terms are missing from the database. Fixing the mapping after a sample is much cheaper than discovering the same mistake across thousands of records.

Ask the freelancer to record problems found during the sample and the resulting changes to the mapping. That record becomes the first version of the migration notes, and it prevents a later handoff from relying on memory.

4. Set rules for content cleanup and editorial handoff

Migration is a poor time to make unrecorded editorial decisions. Agree in advance what happens to obsolete drafts, duplicate pages, unsupported field values, and content marked for review. One practical rule might be to migrate published content by default while keeping drafts in a separate review list; the exact choice depends on the site’s publishing process.

Duplicates need a clear owner. The freelancer can flag records with matching titles or URLs, but an editor should decide whether to merge, delete, or retain them. If two Drupal pages contain different information despite similar titles, an automatic cleanup could remove useful material. Keep a decision log with the source URL, chosen action, and responsible editor.

Set a rule for embedded media as well. Some Drupal content may refer to files stored in a legacy location or embed a video using an old provider code. Decide whether the freelancer should copy the file, replace the embed, or mark it for editorial review. Unsupported field values should be reported rather than silently discarded; a missing value may affect a product, profile, or legal notice.

Agree who checks the migrated copy and how exceptions will be handed over. For example, the freelancer can produce a spreadsheet of records with missing images, while the editor supplies replacements before launch. A defined handoff keeps technical migration work separate from editorial approval.

5. Validate migrated data beyond visual checks

Visual review catches broken layouts, but it cannot confirm that every field or relationship arrived correctly. Compare Drupal and WordPress records for titles, body text, field values, taxonomy assignments, authorship, timestamps, and media associations. Choose checks that reflect the site’s content model rather than relying on a single homepage review.

Where possible, use exports or database queries to compare record counts and selected fields. If there are 240 Drupal event entries in scope, the migration report should account for the destination records or list the specific exclusions; do not assume the count matches without checking. If the final total is not yet known, mark it for verification instead of inventing a target.

Test relationships in the live WordPress interface too. Open a taxonomy archive and confirm that an article assigned to a term appears there. Check an author archive if authorship drives navigation. Open several media-heavy items and confirm that the images or attachments belong to the right records, not merely that the files exist somewhere in the media library.

Document exceptions with enough detail to act on them: source identifier, destination URL, issue, owner, and status. A note such as “some images are wrong” is difficult to resolve. A note naming the affected article and the missing image gives the freelancer and editor a concrete task.

6. Plan the cutover around content changes

Content may continue to change while the freelancer builds WordPress. Choose either a content freeze or a final-delta process before migration begins. With a freeze, editors stop publishing in Drupal for an agreed period while the final transfer and checks take place. With a delta process, the freelancer imports the initial content and then transfers records created or changed after that point.

A freeze is simpler to explain, but it can disrupt a busy newsroom or organization. A final delta allows continued publishing, yet it needs a reliable way to identify changed records and avoid duplicates. Ask who will track changes, when the last import will run, and how updates made during the cutover will be checked.

Set a launch checklist with specific gates: final import completed, priority pages reviewed, redirects tested, forms submitted successfully, and content owners notified. If a critical item fails, define whether launch pauses or whether the issue has an approved workaround. The decision should be made before the pressure of launch day.

7. Close out access, documentation, and rollback readiness

At handoff, confirm that the freelancer has delivered the migration scripts, field mapping, exception log, and instructions for running any final import. Ask for notes on custom post types, taxonomies, scheduled tasks, and any manual steps that a future maintainer will need. A script without instructions may be difficult to reuse when the site needs a correction months later.

Review account access as well. Remove temporary accounts or reduce permissions that are no longer needed, and rotate credentials if they were shared for the migration. Keep one named owner responsible for WordPress administration so the site does not depend on an old contractor’s personal login.

Rollback readiness means preserving a restorable copy of the Drupal site and knowing who can restore it if the new site has a serious launch problem. Agree on the backup location, restoration responsibility, and the conditions that trigger a rollback. Do not remove the old site simply because WordPress is live; retain it until the agreed checks pass and the team has confirmed that important content and workflows work as intended.