Private equity and portfolios
Migrating customers from an acquired product onto your platform: data checks
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Before you migrate customers from an acquired product to your platform, confirm six things: the contract permits the move, the DPA and sub-processor list are updated, the hosting region still matches what was promised, notice goes out on time, fields map without loss, and the old system is archived. Never let a migration carry new data-use terms.
Key takeaways
- A forced migration is a contract event, so read each customer's agreement for service, hosting and assignment clauses before announcing dates.
- Moving customers onto a new platform usually adds sub-processors, and many DPAs require advance notice and an objection window.
- Keep data-use terms unchanged during migration; FTC staff warned in 2024 that quiet, retroactive terms changes for AI training may be unfair or deceptive.
- Map every object and field, including attachments, audit history and custom fields, and tell customers what will not move.
- Archive the acquired product's own records, such as support tickets and engineering history, before decommissioning, and decide their future deliberately.
What must be true before you move any customer?#
Before you move any customer from an acquired product, your team must be able to show that the customer's contract permits the move, that privacy commitments survive it, and that nothing the customer relies on will be lost. Migration is a product decision for you, but for the customer it changes who processes their data, where, and under which vendor stack.
Group CTOs tend to plan the technical cutover first and bring in legal late. Reverse that order. A short contract and DPA review across the acquired customer base tells you which accounts can move on standard notice, which need consent or an amendment, and which may have to stay on the old product until renewal.
| Check | What to read | What stops the move |
|---|---|---|
| Contract permits the move | MSA, order forms, service description, assignment clause | Product named as a fixed deliverable, or no right to change how the service is delivered |
| DPA and sub-processors | Data processing agreement, sub-processor list, notice terms | Objection exercised, or the notice period has not yet run |
| Hosting region | Data location commitments, security exhibits, completed customer questionnaires | A promise to keep data in a region your platform does not serve |
| Notice timing | Notice clauses, end-of-life provisions, renewal dates | Notice shorter than the contract requires |
| Field mapping | Data models of both products, customer customizations | Records that cannot be represented without loss |
| Archive of the old system | Retention schedule, deletion commitments, legal holds | No plan for records before infrastructure is shut down |
Which contract clauses decide whether customers can be moved?#
The contract clauses that decide whether customers can be moved are the ones defining the service, the entity providing it and the customer's right to object or exit. Read master agreements and order forms together, because older acquired products often carry custom paper the previous owner negotiated account by account.
Watch for contracts that name the product, describe specific functionality or attach a feature list. A promise of a named application with listed features is harder to satisfy with a different platform, even one that does more. If the contracting entity also changes, the assignment clause and any change-of-control language come into play.
- Service definition: does it name the acquired product, or describe outcomes your platform also delivers?
- Modification rights: may the provider change the service, and with what notice?
- Assignment: can the contract move to another group entity without consent?
- Termination: does a platform change give the customer an exit or refund right?
- Security exhibits: do they reference specific certifications, controls or hosting providers?
- Data return: what format and window were promised if the service changes or ends?
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
How do DPA, sub-processor and hosting region commitments change?#
DPA and sub-processor commitments usually change in a migration because your platform runs on different infrastructure, support tools and vendors than the acquired product. Every new vendor that touches customer personal data may be a sub-processor the customer has a right to hear about before processing starts.
Compare the two sub-processor lists side by side and mark every addition. Many DPAs require advance notice of new sub-processors and give customers time to object, so the notice must go out before data moves, not on cutover day. If the acquired product promised hosting in a specific region, confirm your platform can honor that for each affected customer or plan an exception.
Customers outside the US add another layer. GDPR and similar laws may apply to how data moves between regions and vendors, and transfer mechanisms in the old DPA may not cover your platform's vendors. Those questions are assessed customer by customer with counsel.
Why migration notices must not change data-use terms#
Migration notices should change where and how the service runs, not what you may do with customer data. Bundling a broader data-use clause, such as permission to train AI models on customer content, into a platform move turns a technical project into a trust and regulatory problem.
A February 2024 post from FTC staff made the risk explicit: a company that starts using consumers' data in more permissive ways, AI training among them, and announces the shift only by quietly and retroactively editing its terms of service or privacy policy may be acting unfairly or deceptively. Business customers read migration paperwork with the same suspicion, and procurement teams compare it line by line.
Keep acquired customers on equivalent data-use terms through the move. If the group wants new terms, introduce them separately, at renewal, with clear notice and an explicit choice. A good notice covers the points below.
- What changes: platform, hosting location, support channels and sub-processors.
- What does not change: data ownership, permitted use and confidentiality terms.
- Timeline: migration window, read-only period for the old product and final shutdown date.
- Customer actions: mapping review, user re-invitations and integration updates.
- Export option: how to download data from the old product before shutdown.
Field mapping: where customer records get lost#
Field mapping is where customer records get lost, because two products rarely model the same work the same way. Custom fields, attachment limits, status values and user roles that made sense in the acquired product may have no clean home on your platform.
Build the mapping from real customer data, not documentation. Pull accounts with heavy customization, map every object, and record what is transformed, merged or dropped. Share the dropped items with customers before their migration window and offer an export of anything that will not move.
| Object in the old product | Common loss | Mitigation |
|---|---|---|
| Custom fields | Truncated values or fields with no target | Create target fields or attach an export |
| Status and workflow values | Many old statuses collapsed into a few | Keep the original value in a legacy field |
| Attachments | Size or file type limits on the new platform | Move to linked storage with a reference |
| Audit logs and history | Only the current state migrates | Export history to a read-only archive |
| Users and permissions | Role mismatches and orphaned record owners | Customer admin reviews roles before cutover |
| Integrations and API keys | Broken connections on day one | List every integration and reissue credentials |
What to archive from the old system before shutdown#
Before the acquired product is shut down, archive two different things: customer data you must return or delete under each contract, and the company's own operating records, such as support tickets, engineering issues, code reviews and release notes. The first follows customer instructions. The second belongs to the business and deserves a deliberate decision.
Customer data follows the contract: export windows, return formats and deletion certificates, with legal holds and tax or audit retention checked before anything is deleted. Internal records are different. Support conversations linked to engineering fixes are often the most complete history the acquired team ever produced, and they usually disappear when the help desk subscription lapses.
Record who owns the archive, where it lives, what it contains and which restrictions came from customer contracts. That index makes later decisions about internal reuse, exit diligence or licensing far easier than reconstructing history after vendor accounts are closed.
Illustrative: moving a scheduling product onto a field service platform#
Illustrative: a fictional vertical software group acquires a small scheduling product used by landscaping contractors and decides to move its customers onto the group's larger field service platform. The acquired product runs in a separate cloud account with its own help desk, issue tracker and email provider.
The contract review shows most customers accepted click-through terms that allow service changes on notice, while several larger accounts negotiated agreements that name the scheduling product and promise US-only hosting. The group sends sub-processor notices first, moves the click-through customers in waves, and leaves the negotiated accounts on the old product until their renewals.
Field mapping shows recurring job templates have no direct equivalent, so the team adds a legacy template field. Before shutdown, it exports help desk tickets and linked issues into an indexed archive owned by the group, flags tickets carrying customer attachments, and defers any decision about further use.
How SourceX approaches records left after a migration#
SourceX does not run migrations; it helps groups decide what to do with the internal records an acquired product leaves behind. Using the SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, a group can test whether retired support and engineering history is licensable, starting with a fit check that collects metadata, not files.
If a package proceeds, the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization, so customer-data carve-outs made during the migration stay documented. Data is licensed, not sold, and the group keeps ownership.
Frequently asked questions
Do we need customer consent to move them to a different platform?
It depends on the contract. Some agreements let the provider change how the service is delivered on notice; others name the product, promise specific features or restrict assignment, which can require consent or an amendment. Review the master agreement, order forms and DPA for each customer segment, and treat negotiated contracts separately from click-through terms.
Can we keep running the acquired product for a few customers?
Yes, and it is often less risky than forcing a move. Keeping negotiated accounts on the old product until renewal avoids breach claims. Budget for security patching, sub-processor upkeep and support coverage during that period, and give those accounts a clear migration offer when renewal talks begin.
Should migrated customers sign our standard platform terms?
Eventually, usually at renewal. A move onto your platform does not require new terms if the old contract allows the change, and forcing new paper mid-term invites objections. When you introduce standard terms, explain material differences, especially on data use, retention and liability, rather than relying on a click-through prompt.
What happens to the acquired product's support tickets after shutdown?
Tickets the company created and holds are usually its own records, though they contain customer names and content. Export them before the help desk subscription ends, store them with an index and a named owner, and note any contractual deletion commitments. Decide later whether they serve internal training, diligence or licensing.
Who should own the migration checklist?
The group CTO usually owns the technical plan, and the general counsel owns contract, DPA and notice decisions. Give one person the combined checklist so no account moves until both sides sign off, and keep a per-account status record that survives staff changes.
Sources
- On February 13, 2024, FTC staff warned that a company adopting more permissive data practices, such as using consumers' data for AI training, and disclosing them only through a surreptitious, retroactive change to its terms of service or privacy policy may be engaging in unfair or deceptive practices. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.