Property Management Website Migration: URLs, Tracking, Cutover, and Rollback
Plan a rebuild or platform move with a URL inventory, redirect map, tracking baseline, tested owner journey, launch owner, and recovery procedure.
Luke R.
Co-founder, DoorHQ
Key takeaways
Commercial pages this guide supports
Recommended next step
Turn this topic into a clearer website and SEO plan.
DoorHQ can review your site, keyword targets, internal links, and owner inquiry path so you know what to fix first.
Practical checklist
7 points to work through.
- 1Inventory URLs, accounts, forms, portals, and tracking before building the replacement.
- 2Map each changed URL to its relevant destination and test the map on production.
- 3Assign cutover and rollback decisions before launch, including how new inquiries are preserved.
- 4Review the define what is changing and who can reverse it section and turn it into one on-page improvement.
- 5Review the inventory the old site and save a baseline section and turn it into one on-page improvement.
- 6Review the build a url map with an explicit decision for each row section and turn it into one on-page improvement.
- 7Review the prepare the replacement site before switching traffic section and turn it into one on-page improvement.
Related reading
Define what is changing and who can reverse it
A new design on the same URLs, a CMS change, a hosting move, and a domain change are different migration jobs. List which are actually in scope. Keeping useful URLs stable can remove avoidable redirect work when the page's purpose is unchanged.
Name a launch owner who can coordinate the developer, domain administrator, sales team, and software vendors. Record account access without copying passwords into the launch sheet. The business should know who controls the domain, hosting, CMS, analytics, Search Console, and each portal or form destination.
Agree a cutover window, an acceptance checklist, and the person who can stop or reverse launch. Avoid launching when nobody can verify lead delivery or restore the agreed previous version.
Inventory the old site and save a baseline
Collect URLs from the sitemap, a crawl, Search Console, analytics, campaigns, and known owner or resident bookmarks. Include downloadable resources and old contact or portal paths. Ask staff which links they routinely send to clients; those may matter even if search traffic is low.
Save recent search and inquiry reports with date ranges and definitions. Record analytics property and tag identifiers, event names, consent behavior, form routing, and third-party destinations. Export content and keep appropriate backups of the website and its configuration before changing them.
For a hosting or domain change, inventory relevant DNS records with the responsible administrator. Website work should account for existing email and other services using the domain. A migration plan is incomplete if it preserves the homepage while unintentionally disrupting mail or client access.
Apply this to your site
DoorHQ can turn this topic into pages, metadata, forms, and tracking for your market.
Build a URL map with an explicit decision for each row
Google recommends mapping old URLs to their new counterparts and using permanent server-side redirects for permanent moves where possible. Point directly to the appropriate final destination. A broad redirect of unrelated deleted pages to the homepage does not preserve their original purpose.
The following rows are illustrative paths, not instructions to change a real site. Keep the content decision and the technical response in the same sheet so the developer knows why each rule exists.
| Old path | Decision | Expected live behavior |
|---|---|---|
| /property-management | Keep the same service and path | 200 with the refreshed content and intended canonical |
| /services/management-old | Move to /property-management | 301 or 308 directly to the final relevant page |
| Two repetitive fee articles | Merge useful material into one guide | Surviving guide works; retired URL redirects to it |
| A discontinued service with no useful replacement | Remove or publish an accurate explanation if useful | Agreed missing-page response or substantive replacement; no deceptive homepage redirect |
| /resident-login | Keep the familiar route to the approved vendor | Client reaches the correct portal with a tested link or redirect |
Prepare the replacement site before switching traffic
Check the core pages, navigation, forms, portal links, images, and content on a phone and desktop. Keep preview content protected from premature discovery. Document which preview restrictions must be removed at launch and which authenticated areas must remain protected.
Review the preferred URLs, canonical tags, sitemap, and internal links as one system. On the new site, links should use final destinations rather than rely on old redirects. Test missing pages, redirects, query-string handling where needed, and any downloadable resources clients still use.
Verify vendor-dependent work before cutover. A booking widget loading in preview does not prove a confirmed booking reaches the correct staff calendar. A form success screen does not prove the inquiry reached sales. Use authorized test details and retain the result of the full route.
Preserve measurement continuity
Decide which existing analytics property and events should continue and document any deliberate change. Compare the old and new event definitions: a newly named event is not automatically a different business outcome. Check for duplicate tags and repeated success events.
Submit a test owner inquiry, open the resident portal, and test a booking if included. Confirm that analytics distinguishes the actions and that the lead system receives the inquiry once. Record the launch date in your change log so later traffic changes can be compared with the release.
Separate tracking success from delivery success. Analytics can fail while an inquiry arrives, and an event can fire while delivery fails. Both need their own test and owner. Keep personal contact details and property addresses out of analytics parameters.
Use a cutover checklist with a real rollback trigger
Back up the current release and configuration, confirm who can change routing or DNS, and ensure the planned previous version is available if needed. Run the approved deployment and routing changes, then immediately test production using the URL map and owner journey.
Define serious failures in advance, such as unavailable priority pages, broken inquiry delivery, incorrect portal routing, or a site-wide indexing restriction. Agree whether the team will fix forward or restore the previous version, who makes that decision, and how quickly they must respond.
Rollback is not simply restoring an old database. Preserve inquiries and other records created after cutover, keep a log of what changed, and assess redirect and domain effects before reversing them. If a domain or URL move has already been exposed publicly, careless reversal can create another inconsistent state.
| Launch checkpoint | Owner | Required evidence |
|---|---|---|
| Production URL checks | Developer | Expected status and final destination for mapped URLs |
| Owner inquiry receipt | Sales and developer | One test reaches the assigned person and confirms success |
| Portal and booking destinations | Operations | Correct vendor account and successful test path |
| Search instructions | SEO or developer | Live canonicals, robots rules, and sitemap match the launch plan |
| Acceptance or rollback decision | Launch owner | Timestamped decision and unresolved issue owners |
Monitor after launch without repeatedly changing direction
Inspect representative URLs in Search Console, review the new sitemap, and follow Google's domain-move guidance if the domain actually changed. Keep applicable redirects for at least a year, as Google recommends, and longer where users or external links still depend on them.
Review server errors, missing paths, inquiry delivery, and relevant search performance after launch and on an agreed recurring schedule. Compare equivalent periods and allow for the sales cycle. Search changes can occur during a move; a temporary fluctuation alone does not tell you which technical action to take.
Close the project with a URL map, launch test record, account and handover register, open-issue list, and assigned maintenance responsibilities. These records make the next update safer and make the completed work reviewable.
Sources and further reading
FAQ
Frequently asked questions.
Do I need to change every URL when rebuilding?
No. Keep a useful existing URL when the page's role remains appropriate. Change it for a clear reason, then map and test the redirect rather than assuming a cleaner-looking path justifies the disruption.
Can a migration guarantee no search traffic loss?
No. A careful plan reduces avoidable mistakes but cannot guarantee how search systems will process the change. Preserve evidence and monitor technical behavior and relevant inquiries after launch.
Should we cancel the old hosting immediately?
Only after checking what still relies on it and agreeing the redirect, rollback, backup, and account-retention plan. A working new homepage alone does not prove that every dependency has moved.
