Moving on-premise customers to your cloud product: a vendor's data checklist

What changes when customer data moves onto your servers?#

Hosting changes your role: once a customer's production database runs in your cloud, you hold their records on their behalf, usually as a processor under a data processing agreement. In the on-premise era you saw that data only when a customer opened a remote session or attached a database backup to a support ticket.

The shift touches every team. Engineering now owns backups and restores, support engineers can reach live tenant data, finance moves from license and maintenance revenue to subscriptions, and legal inherits breach notice, subprocessor and deletion duties. Run the migration program as a data custody project as well as a product launch.

Contract checklist before the first migration#

The contract checklist starts from one fact: perpetual license and maintenance agreements were written for software the customer runs, so they rarely authorize you to host, back up or access the customer's data. Each migrating customer needs a subscription agreement or hosting addendum signed before any data moves.

Write the documents once as templates, then negotiate exceptions. Enterprise customers will send their own security exhibits, and having standard positions ready keeps the migration calendar from stalling in legal review.

• 1Subscription agreement or hosting addendum that replaces or supplements the perpetual license and maintenance terms.
• 2Data processing agreement naming you as processor, listing processing purposes and explaining how customer instructions are given.
• 3Subprocessor list covering the cloud provider, email delivery, monitoring, support tooling and any offshore support team.
• 4Security exhibit describing encryption, access control, logging, vulnerability management and penetration testing.
• 5Breach notification clause with a process your team can actually run at night and on weekends.
• 6Data return and deletion terms with a defined export window after termination.
• 7Usage data clause stating which operational telemetry and aggregated statistics you may keep and use.
• 8Migration statement of work covering data mapping, validation, cutover and customer sign-off.

Where will the data live, and who can touch it?#

Hosting region and access paths are the questions regulated customers ask first, so answer them in writing before sales improvises. Pick a default region, decide whether you will offer others, and document which people and systems can read tenant data.

Support access deserves its own rule. On-premise support engineers worked through screen shares the customer controlled; in the cloud they may be able to open any tenant. Many vendors require a ticket reference and customer approval for tenant access, log every session, and stop support tooling from copying tenant records into tickets.

Map indirect copies too. Error monitoring tools capture request payloads, product analytics capture page content, and data warehouses replicate production tables. Each is a place where tenant data now lives, and each must be covered by your DPA and your deletion process.

What customer data will you hold for the first time?#

The customer data you will hold for the first time is usually broader than the product's core tables: years of transaction history, scanned documents, personal data about the customer's own employees and clients, and credentials for integrations with payroll, banking or tax systems. Inventory these categories for each product before migration tooling is built.

Decide whether to migrate full history or only active records. Moving everything by default is simpler for engineering but makes you the custodian of records the customer may no longer need. A common alternative is to migrate active years and give the customer an archive export of older history to keep under its own control.

Customers will also ask how they get data and attachments back out. Vendors making the same move are setting this out early: a post on the EpiUsers community forum about Epicor Kinetic moving to the cloud says Epicor is outlining export options for data plus attachments, including which exports can be automated and which need assistance.

Exit and deletion terms: decide them before customers ask#

Exit and deletion terms tell a customer how long it can retrieve its data after the subscription ends and when you will delete it, backups included. Cloud buyers compare these terms across vendors, so set a clear window rather than promising to handle departures case by case.

Large platforms publish theirs. Microsoft's Trust Center says that when a cloud subscription ends, customer data is kept in a limited-function account for 90 days so the customer can export it or renew, and is then deleted within a further 90 days. The Salesforce Main Services Agreement makes customer data available for export if the customer asks within 30 days after termination or expiration.

Whatever window you choose, make sure engineering can execute it: a working self-service export, a deletion job that reaches replicas and backups, and a deletion confirmation process for customers who ask for one in writing.

Which records stay yours after the move?#

The records that stay yours are the ones your company creates to build and run the product: source code, code reviews, issue histories, release records, incident postmortems, support conversations and product decisions. Customer content stored in tenants remains the customer's, and a DPA usually limits you to processing it for the customer's purposes.

Write that boundary into an internal data use policy now. Migration is the moment tenant data starts flowing into your logs, warehouses and tickets, and it is far harder to separate afterward. Tag tenant-derived fields in the warehouse, keep customer files out of tickets where possible, and record which usage statistics your contracts let you keep.

Illustrative example: a job costing vendor moves to hosted#

Illustrative: a fictional mid-sized vendor sells a Windows-based job costing system to specialty contractors, installed on SQL Server at each customer site. It decides to move customers to a hosted version at renewal, with support in Zendesk, engineering in Jira and GitHub, and documentation in Confluence.

Before the first cutover, the CTO and outside counsel publish a DPA, a subprocessor list and a hosting addendum, and the support team adopts a rule that tenant access needs a ticket and customer approval. The company migrates active jobs and gives each customer an archive export of closed projects. Its internal policy treats tenant data, usage aggregates and company records as three separate classes.

Later, when the board asks whether the company's own records could be licensed, the answer comes quickly. Support conversations, Jira issues and code reviews are already separated from tenant data, and the contracts already state what the company may keep.

How SourceX treats tenant data and platform records#

SourceX scopes a software vendor's records by owner before anything else. In the Supply and Rights steps of the SourceX five-step transaction, tenant data held as a processor is generally excluded, while company records such as support conversations, issue histories, code reviews and release notes are assessed for fit, with customer details removed during Preparation.

The fit check uses metadata only: system names, record families, years of accessible history and known contract limits. If a package proceeds, the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization, so the boundary you drew during migration is documented for the buyer.