Website Redesign Data Migration for Content, URLs, and Accounts

A technical runbook for planning and executing a website redesign data migration, covering inventory and field mapping, URL redirects, content and media transfer, and form and user account migration, with rollback and verification steps.

Inventory and Field Mapping for Content, URLs, and Accounts

Start by creating a complete inventory of all digital assets affected by the redesign. This includes content pages, media files, URLs, redirects, forms, user accounts, analytics tags, and third-party integrations.

Use a spreadsheet or database to record each item with its source location, type, owner, and dependencies.

For content, list every page, post, or custom post type, noting the current URL, title, metadata, and associated media. For media, record file paths, alt text, and usage across pages.

For URLs, capture the full path, query parameters, and any existing redirects. For forms, document the form ID, fields, and submission handling. For user accounts, note usernames, email addresses, roles, and permissions.

Next, map fields between the old and new systems. Create a mapping table that pairs each old field with its new counterpart.

For example, map old content type to new taxonomy, old image URLs to new media library paths, and old user roles to new permission sets. Include transformation rules for data that changes format, such as date fields or custom metadata.

Document the environment and preconditions. Record the content management system versions, database versions, and any custom code that may affect migration. Ensure you have a staging environment that mirrors production for testing.

Verify that you have full backups of the source database and files, and that you can restore them if needed.

Create a sampling checklist to validate the inventory. Select a representative sample of content types, URLs, and user accounts to verify that the mapping is accurate.

For each sample, confirm that the field values are correctly transformed and that no data is lost.

URL Mapping and Redirect Strategy

Create a URL mapping table that pairs every old URL with its new destination. This table should include the old path, the new path, and the redirect type. Use 301 redirects for permanent moves to preserve search engine rankings and user bookmarks.

Use 302 redirects only for temporary changes.

For pattern-based redirects, define rules that handle groups of URLs. For example, if you are changing the URL structure from /category/post to /topic/post, you can use a wildcard rule to redirect all posts under a category.

Implement these rules in the server configuration or through a redirect plugin.

Test the redirects thoroughly. Use a tool like curl to send requests to old URLs and verify that they return the correct status code and redirect to the new URL. Check for redirect chains, where a URL redirects multiple times, and eliminate them.

Also, verify that query parameters are handled correctly, either by preserving them or stripping them as needed.

Document the failure branches. If a redirect rule is missing, the old URL will return a 404 error. To recover, add the missing rule and test again. If a redirect points to a non-existent page, update the mapping table and the rule.

Content and Media Migration Execution

Execute the migration of content and media files using scripts or tools. For content, export the data from the old system and import it into the new one. Use the field mapping table to transform the data during import.

For media, transfer files to the new server, preserving directory structure and file names.

Verify file integrity after transfer. Compare file sizes and checksums between source and destination. For images, check that dimensions and formats are correct. For documents, ensure they open without corruption.

Preserve metadata during migration. This includes titles, descriptions, alt text, and custom fields. Use the mapping table to ensure that metadata is transferred to the correct fields in the new system.

Handle embedded media carefully. If a content page includes images or videos, update the URLs to point to the new media locations. Use a search-and-replace script to update references in the content database.

Document the failure branches. If a file transfer fails, check the network connection and retry. If a content import fails, review the error logs and adjust the mapping or data format.

Always have a rollback plan: restore the previous version of the database and files if the migration fails.

Form and User Account Migration

Migrate forms and user accounts, including passwords, roles, permissions, and associated data. For forms, export the form definitions and submissions from the old system and import them into the new one. Map form fields to the new form builder’s fields.

For user accounts, export user data including usernames, email addresses, and hashed passwords. Import the data into the new system, preserving the password hashes.

If the password hashing algorithm differs, you may need to force a password reset for all users.

Plan for password resets and user communication. If you cannot preserve password hashes, send an email to users with a reset link. Communicate the migration timeline and any changes to login URLs or account features.

Verify that user roles and permissions are correctly mapped. Test that users can log in and access the appropriate content. Check that user-generated content, such as comments or profile fields, is transferred correctly.

Document the failure branches. If a user import fails, check for duplicate emails or invalid data. If a form submission is lost, verify the export and import logs. Always have a rollback plan: restore the previous user database and forms if needed.

After migration, perform a final verification. Test key user journeys, such as logging in, submitting a form, and accessing a redirected URL. Document the drill record, including the date, environment, and any issues encountered.

Analytics and Third-Party Account Reconfiguration

Before the new site goes live, you must reconfigure analytics tools and third-party integrations to track the new environment. Start by creating a new property or view for the redesigned site in your analytics platform.

This prevents historical data from mixing with new data and gives you a clean baseline for post-launch comparison.

Update the tracking code or tag manager container to reference the new property ID. If you use Google Tag Manager, publish a new container version that includes the updated tags.

Verify that the tracking snippet fires on the new site by loading a test page and checking the network requests in your browser’s developer tools.

Third-party integrations such as CRM systems, email marketing platforms, and form handlers often rely on API keys or webhooks. Locate the configuration files or admin panels where these credentials are stored.

Replace any API keys that are tied to the old domain with new ones issued for the new domain. Update webhook URLs to point to the new site’s endpoints.

Document every change you make in a configuration log. Include the old value, the new value, the date, and the person who made the change. This log becomes part of your migration record and helps you troubleshoot if an integration stops working after launch.

Test each integration in a staging environment before the cutover. Submit a test form, trigger a test email, and verify that the data appears in the connected system. If an integration fails, check the API key permissions and the webhook payload format.

Pre-Migration Testing and Dry Run

A dry run migration in a staging environment is essential to validate your process and identify data loss or errors before the final cutover.

Set up a staging environment that mirrors your production environment as closely as possible, including the same content management system version, plugins, and configuration.

Create a full backup of your production content, URLs, and user accounts. Restore this backup into the staging environment. This ensures that the dry run starts with the same data that will be migrated during the final cutover.

Execute the migration steps you have planned, including content import, URL redirects, and account transfers. After the dry run, compare the staging site against your migration checklist.

Verify that all content is present, URLs resolve correctly, and user accounts have the correct permissions.

Check for common failure signals such as missing images, broken internal links, or form submissions that do not reach the backend. Use a crawler tool to scan the staging site for 404 errors and redirect chains.

Document any issues you find and refine your migration plan accordingly.

Repeat the dry run if significant issues are discovered. The goal is to reach a point where the migration process runs without errors or with only minor, documented issues that you can handle during the final cutover.

Cutover, Verification, and Rollback Plan

On the day of the final migration, execute the steps you validated during the dry run. Begin by placing the production site into maintenance mode to prevent new content from being added during the migration.

This ensures that the data you migrate is consistent.

Take a final backup of the production database and files. Store this backup in a separate location from the live server. This backup is your primary rollback asset if the migration fails.

Run the migration process, including content import, URL redirects, and account transfers. After the migration completes, switch the DNS to point to the new hosting environment if applicable.

DNS changes can take time to propagate, so plan for a transition period.

Verify the new site thoroughly. Check that key pages load correctly, forms submit, and user logins work. Use a crawler to identify broken links and missing redirects. Monitor server logs for errors.

If you encounter a critical failure that cannot be resolved quickly, execute the rollback plan. Restore the production backup to the original environment and switch DNS back. Communicate the rollback to stakeholders and document the reason for the failure.

Post-Migration Monitoring and Documentation

After the cutover, monitor the new site for errors, broken links, and performance issues. Set up uptime monitoring and check server logs daily for the first few weeks.

Use a web analytics tool to track traffic patterns and identify any sudden drops that might indicate a problem.

Watch for 404 errors, especially for old URLs that should have been redirected. Use a redirect checker to verify that all old URLs point to the correct new pages. If you find missing redirects, add them immediately.

Monitor form submissions and other user interactions to ensure that data is being captured correctly. Check that email notifications are being sent and that CRM records are updated.

Document the entire migration process, including decisions, changes, and lessons learned. Create a post-migration report that includes the migration checklist, the configuration log, the dry run results, and the final verification record.

Note any issues that arose and how they were resolved.

Store this documentation in a shared location accessible to the team. This record will be valuable for future migrations and for troubleshooting any issues that surface later.

Regularly review the monitoring data and documentation to identify opportunities for improvement. The migration is not complete until the new site is stable and all stakeholders are confident in its performance.

Next step

Need help executing a website redesign data migration? Contact SHMLANG for expert guidance on content, URL, and account migration.