In a hypothetical migration, a SaaS pricing page displays the approved annual plan while its signup button sends the monthly plan ID. A visual review misses the wrong offer. The configuration, website and signup owners need to test that handoff together.
This website migration checklist covers replacing a SaaS marketing site's CMS or frontend, with retained or changed URLs. Application infrastructure and customer-data migrations need separate plans.
Define what the migration changes
Map the website's boundaries: pricing may move while application signup stays; a rebuilt demo form may still use the same CRM. Include those receiving systems in acceptance tests. A component can stay unchanged while receiving different inputs from the rebuilt website.
Inventory public URLs, separating retained addresses, changed destinations and intentional retirements. Keeping content does not necessarily preserve its paths. Record each intended destination or retirement response so reviewers can distinguish planned removals from accidental missing pages. Focused journey tests supplement that inventory.
If platform selection is still open, test the publishing work your team needs: editing a plan, scheduling an offer, and updating a reusable page component. Check the required content relationships and integrations. For background, see a comparison of WordPress alternatives for SaaS published by Merge Rocks. Base your choice on your own workflow and maintenance capacity.
Record expected behavior and test results
The existing site shows current behavior, which may already be outdated. Have offer and receiving-system owners approve plan IDs, billing periods, promotions and destinations; save the configuration's date and version. Update expectations and repeat affected tests after changes.
Save current titles, meta descriptions, H1s, relevant structured data and essential assets, including images, downloads and scripts. Record performance results, tools and device, network and cache conditions, alongside approved intentional changes. Repeat critical pricing and form checks in supported desktop and mobile browsers using approved test identities. Confirm visitors can change billing periods, see validation errors and complete submission on each supported test device. Record the browser in each result and reference restricted evidence without passwords or full personal details.
This completed PRICE-01 example has fictional inputs, times, references and results. No test was executed.
Test: PRICE-01; staging release example-v1.Time/device/browser: 2026-10-08 10:00 UTC; desktop; Chrome.Input/action: /pricing; new visitor; Pro; Annual; no promotion; click signup.Expected: signup receives pro_annual, annual billing.Observed: signup receives pro_monthly, monthly billing. Result: FAIL.Evidence: PRICE-01-request-1 and PRICE-01-signup-1.Correction owner: frontend engineer fixes Annual mapping.Launch decision: release lead holds annual Pro route.Retest: example-v2, 10:30 UTC; annual receives pro_annual/annual; monthly receives pro_monthly/monthly; both PASS.Release decision: release lead removes route hold.
Follow pricing into signup
For supported monthly and annual choices, compare the displayed plan and billing period with signup's received state. Save screenshots, requests and destinations. Test approved promotions against their eligibility and expiry rules, including both active and approved post-expiry states. Include returning visitors with cached pages or stored selections where relevant; use the team's supported cache-refresh behavior.
Set the boundary by dependencies the migration can affect. If selections continue into checkout, the payment-system owner should verify them in an authorized test environment, even when that system stays unchanged. A verified signup handoff may suffice when checkout inputs and behavior are unaffected.
Restream's website work involved Merge Rocks, a SaaS design and development team. In its public Restream case study, the team reports moving Pug views to Next.js while continuing day-to-day delivery. Within the wider engagement, the team also worked on pricing and login/signup behavior, prepared campaign discount states and rollback steps, and fixed a pricing SEO issue so the page could be indexed properly. The work spanned the marketing site's implementation and the routes visitors use to enter the product. For your migration, identify the owners of those routes and include them in the review. Ask each owner to verify the visitor-facing behavior and the handoff to the system they manage.
Verify account creation and lead delivery
Complete signup with an approved new identity. Verify the account in the application and, where required, receive and complete email verification in the designated inbox.
For signup and demo forms, try an empty required field and invalid email, then correct errors and submit without losing other values. Follow the corrected submission to its destination. Test an existing identity against the agreed sign-in prompt or account-exists response. Record that expected response so a deliberate refusal to create another account does not look like a broken flow.
Follow a traceable demo lead to the actual inbox or CRM record. Verify fields and the assigned owner or queue where routing applies. A success banner or analytics event cannot establish delivery. Have the engineer and receiving-system owner investigate using the same test ID and timestamp.
For confirmed delivery failures, hold the route or use an approved working alternative. Check whether real submissions need recovery before retesting could create duplicates. Missing analytics needs its own investigation.
Test campaigns from the published link
Start with the parameterized email or ad link people will encounter. Follow redirects, inspect the destination's offer and complete the intended signup or lead action. Check captured campaign fields in the receiving record where designed. Capture may happen before redirects; use the agreed mechanism rather than requiring parameters in each URL.
Repeat with an expired offer. Have the campaign owner define the approved destination and behavior, then verify the destination applies that rule. That might mean a standard offer or an explanation that the promotion has ended. Opening a CMS preview skips the published route.
Enable debug mode on a controlled device and inspect received events in GA4 DebugView. Compare names and required parameters with the tracking specification; record consent because privacy controls affect visibility. DebugView has limited attribution analysis. Check processed Acquisition reports later for accurate attribution information.
The campaign owner can pause traffic reaching a wrong offer while the team repairs it. Missing analytics evidence calls for consent and instrumentation checks before concluding delivery failed.
Check URL continuity and search eligibility
Compare production content, structured data and assets with the baseline and approved changes. Repeat performance measurements using comparable tool, device, network and cache conditions; investigate unexplained regressions. Keep lab and real-user field measurements separate: a lab pass does not establish field Core Web Vitals results.
For retained URLs, check responses and rendered content at the same addresses. Remove temporary staging crawl or indexing blocks from pages intended for search. Google's guidance for hosting changes without URL changes covers setup testing and serving/crawling monitoring.
For changed URLs with replacements, map old addresses to relevant destinations using appropriate permanent redirects. Test the full route, update internal links and sitemap destinations. Retired pages without replacements can return 404 or 410. See Google's guidance for moves with URL changes.
Canonical tags signal a preferred URL for duplicate or similar content; check the intended production address. Google may select another. In Search Console's URL Inspection tool, distinguish current live access and indexing eligibility from dated indexed data and Google's selected canonical. A successful live test or submitted sitemap does not guarantee index inclusion.
Treat unintended crawl blocks or wrong destinations as launch blockers. Record the crawl date and follow up when indexed data reflects an earlier state.
Agree when to repair, pause or restore
Name who can authorize launch and stop affected routes. Match the response to the failure's reach and changed layer: repair a plan mapping, pause a campaign, or hold a release for a shared integration losing submissions. Retest repaired paths.
Before choosing restoration for a larger failure, confirm access to a previous build, compatibility with current configuration and receiving systems, and rehearse restoration in a suitable environment.
A frontend restore does not reverse accounts, CRM records or financial writes. Receiving-system owners must review and reconcile affected records using retained evidence. Give accepted nonblocking defects an owner and review time.
Repeat critical paths on production
Rerun pricing, account, lead, campaign and selected search routes on production; record version and time. Use approved identities and agreed cleanup. Staging cannot verify production endpoints or receipts.
Monitor affected signup routes, form receipts, campaign destinations and changed search pages. Sitewide traffic can hide a failed route or reflect a different marketing schedule. Assign owners, review schedules and escalation thresholds using the prelaunch baseline, campaign activity and tolerance for missed transactions. Set different observation windows for immediate account creation and slower search recrawling/reporting. Schedule an owner to recheck the published campaign link and approved destination behavior after expiry.
