A domain upgrade checklist
Inventory old links, email, accounts, and printed assets before announcing a new address.
Start with the business that has to keep working
A domain upgrade can look simple from the outside: announce a new address and point people toward it. Inside the business, the old address may be woven through account systems, customer messages, documents, and partner relationships. The useful checklist begins with those dependencies, because a cleaner public identity should still lead people to the service they expect.
This guide is a planning aid for a move, not a promise of higher traffic or a substitute for checking the systems you actually use. Assign technical work to the people responsible for those systems. Keep the scope clear: acquiring the domain, preparing the website, changing email, and announcing the move are related tasks with different readiness checks.
Record the reason for the change
Write one paragraph explaining what the upgrade is meant to improve. Perhaps the new address matches the brand without an extra word, or replaces a URL that staff repeatedly have to clarify. Keep the explanation concrete. It will help the team decide which changes belong in the move and which can wait for another project.
Choose the public message at the same time. If the business and product are unchanged, say that plainly. If other changes are happening too, separate them in the announcement. Customers should be able to tell whether they need to update a bookmark, use a different login, or simply recognize a new address in future messages.
Build an inventory before setting the date
Create a shared list of every place the old URL appears. Start with the website, then ask people in support, finance, operations, and sales for the materials they use. Include forms, account screens, receipts, downloadable guides, presentation files, social profiles, and advertising destinations. Record an owner for each item so the list can become a work plan.
Add less visible dependencies: connected applications, approved callback addresses, payment settings, and services that send automated messages. The exact list will depend on the business. Mark whether each item can be changed directly, needs another team's help, or depends on an outside provider. Those distinctions are often more useful for scheduling than a single target date.
Map the pages people already know
List important old URLs and their intended new destinations. Preserve useful page relationships instead of sending every visitor to the homepage. A person arriving from a saved support link has a different task from someone discovering the business for the first time. The move should respect that difference where the corresponding content still exists.
Google's documentation for site moves with URL changes covers preparation, URL mapping, redirects, and testing. Review it with the person handling search and hosting. Keep your own map small enough to maintain but detailed enough to cover the pages that matter to customers and incoming links.
Give redirects an owner and a test
Decide who will configure the old address to send visitors to the new one, and who will verify the result. Check real examples rather than accepting “redirects are done” as a complete status update. Include a deep page, a URL with a query string where relevant, and the main domain variants the business uses.
Google also explains the role of permanent server-side redirects when a page has moved permanently. Choose the implementation with the responsible technical team. Avoid adding multiple unnecessary hops through intermediate addresses; keep the customer's route understandable and test it from an ordinary browser as well as through technical checks.
Plan email independently of the website
List active mailboxes, aliases, contact forms, and every service that sends mail using the domain. A working website does not show that email is ready. Ask the email administrator to prepare the new address and the authentication settings required by the actual providers. Keep that work visible as its own set of tasks.
Think about old conversations as well as new ones. Customers may reply to a message sent months earlier, or keep an address in their contacts. Decide how those replies will be handled and how long older addresses need to remain available. The answer should reflect real operating needs and the team's ability to maintain the arrangement.
Check customer recognition and account access
Review the points where a different domain could surprise someone. A login link, receipt, password reset, or support response may be treated cautiously when its address changes. Explain the move through an existing trusted channel before relying on the new identity alone. Keep the announcement factual and avoid asking customers to take unnecessary security-sensitive actions.
Test account journeys using designated accounts. Confirm where links land, whether expected sessions work, and whether any connected service rejects the new address. Record the system owner and the observed result. If a critical journey fails, the checklist should make that visible before the announcement rather than leaving the support team to discover it through customers.
Work through the customer-facing assets
Update the inventory in a sequence that follows use. Website navigation and core messages may change at launch. A downloadable guide might need a revised file and a checked link. A partner listing may need an email request. Printed materials can require a replacement plan based on how long they remain in circulation.
Do a plain-text search of editable documents where possible, but also review images and exported files. An address embedded in a graphic will not always appear in a text search. Ask someone unfamiliar with the update to inspect a sample customer journey. A fresh reader can notice an old URL that the people making the changes have stopped seeing.
Decide what would delay the announcement
Write the launch criteria before the final review. Identify the journeys that must work, the changes that can follow later, and the person who makes the decision. This prevents a minor cosmetic issue from receiving the same attention as a broken account link. It also gives the team a clear reason to pause if an essential dependency remains unresolved.
Keep a fallback note for the parts that can be reversed. Record who has access, what would be restored, and which outside systems might take time to respond. This is not an invitation to rush because a rollback exists. It is a way to make responsibility clear when the team is under pressure and needs to act carefully.
Finish with a short observation period
After the move, review the ordinary signals the business already uses: customer reports, broken-link findings, form behavior, and account support issues. Compare observations with the original inventory. Keep a place for unexpected old references so they can be corrected without losing track of the larger move.
The first useful action is to list every place the old address appears. Do that before announcing a date or rewriting the whole website. A domain upgrade is easier to manage when the work is visible, the owners are named, and success means people can still complete the tasks they came to do. The new address should become familiar through reliable use.