A migration page should tell a buyer exactly what moves from the product they use now, what does not, who does the work, how long a switch takes for a stated kind of setup, and how the two systems run side by side during the overlap. Describe the other product only where you can do it accurately from its own public documentation, and date that description. Hold evidence for every speed or completeness claim before the page goes live.
For many software buyers the real objection may not be your product. It is the years of records, workflows, and integrations sitting in the tool they already pay for. A page headed "Switch from [competitor]" that turns out to be a feature comparison with a button leaves that objection exactly where it was, and sales ends up answering it on every call.
This is a content-planning question for software owners and marketing leads, not legal advice. Naming a competitor's product and making claims about it are matters for your counsel to review before publishing. For the wider page set, see our guide to content for SaaS companies.
What a migration page has to answer
The buyer asking about migration is usually the administrator or operations lead who will do the work, not the person who found the product. Their questions are concrete:
- Which records come across, and does history come with them (comments, timestamps, attachments, owners)?
- What does not come across, and what do we rebuild by hand?
- Is it a self-serve importer, a file upload, or a service your team runs?
- Who maps our custom fields, and what happens to fields with no match?
- How long do both systems need to run in parallel, and how do we keep them in sync during that time?
- Is there a cost for migration help, and what does it cover?
- If the import goes wrong, can we start it again?
A page that answers those questions is doing different work from a comparison page. Our page on writing comparison pages fairly covers which product fits which buyer; this page assumes the buyer is leaning toward you and wants to know what the move costs them. An import button is not a migration plan, and buyers who have moved software before know the difference, so the page should talk about the parts that stay manual as plainly as the parts that are automatic.
Describe the other product's export carefully
You control your importer. You do not control what the other product lets customers export, and that is where most migration pages overreach. Base every statement about the source product on its own public documentation, link or cite that document internally, and put a date on the line, because export options change without notice to you.
The FTC's 1979 policy statement on comparative advertising says the agency "evaluates comparative advertising in the same manner as it evaluates all other advertising techniques." For a migration page, that means a statement about the other product's export is held to the same standard as a statement about your own, so it should be something you could show a source for. Keep these lines factual and narrow: what the export includes, in what format. Characterizations of the other product ("clunky," "locked in") add risk and tell the buyer nothing they can use.
Speed and completeness claims need evidence first
Lines like "switch in a day" and "bring everything with you" are common on migration pages, and both are performance claims. Under the FTC's substantiation policy, the support has to exist first: the statement calls for "a reasonable basis for advertising claims before they are disseminated." Where a claim states its own level of support, such as a test or a count of completed migrations, the statement says the Commission expects the firm "to have at least the advertised level of substantiation."
The practical fix is to attach the claim to a setup. A day may be true for a team with standard fields and no automations, and untrue for a team with years of custom workflows. Before writing any timeline, ask the migration team, "For the last several migrations we ran, how long did each take from first export to go-live, and what made the slow ones slow?" The answer usually produces a better page than the original claim: a typical range for a described setup, and a short list of what lengthens it.
A fictional migration table
Here is a hypothetical table for a fictional project management tool explaining a move from a fictional legacy tracker. It describes no real product.
| Item | Comes across? | How | Notes |
|---|---|---|---|
| Projects, tasks, subtasks | Yes | Self-serve importer | Status values mapped during import |
| Comments and timestamps | Yes | Self-serve importer | Original authors shown as text if the user has not joined yet |
| Attachments | Yes, within the file size limit in the import guide | Self-serve importer | Larger files listed in an import report |
| Custom fields | Partly | Mapped by the admin | Unmatched fields kept as text |
| Automations | No | Rebuilt by the customer | Templates for common rules in the help center |
| Users and permissions | No | Admin invites users; single sign-on set up separately | Permission roles chosen per project |
| Dashboards and reports | No | Rebuilt | Report recipes in the help center |
Every cell in that table came from someone who has run the importer. The writer should not have to guess which fields fail to map, because the migration team sees the import reports and support sees the tickets that follow, and a table written from the product brochure would leave out the rows that matter most to the administrator. Our page on explaining implementation and onboarding covers what happens after the data arrives.
Keep the page honest as both products change
A migration page ages from two directions. Your importer gains and loses capabilities with each release, and the other product changes what it lets customers export. Give the page an owner, put a reviewed date on the source-product lines, and recheck those lines whenever a migration surfaces a surprise. A failed import that a customer reports is the best signal that a row in the table is out of date.
In Hudson South's process, the Authority Asset gathers your import guides, migration runbooks, and the approved answers your team gives about switching. Hudson Twenty-One records how your company communicates across 21 dimensions, so a page about a stressful project sounds like your team rather than a sales script. Market Intelligence researches the questions buyers ask about leaving their current tool, and the gaps competing vendors leave open. AEO Creation turns those inputs into answer-first migration pages that lead with what moves and what does not.
Find the switching questions your site leaves to sales
On a free 30-minute call, the competitor analysis looks at how your pages and competing vendors' pages answer the questions buyers ask before they switch tools.
Get your free competitor analysisSources
- FTC Policy Statement Regarding Advertising Substantiation. Federal Trade Commission. Read 2026-10-16.
- Statement of Policy Regarding Comparative Advertising. Federal Trade Commission. Read 2026-10-16.