A migration can finish loading every row and still leave a team unable to do its job. The customer exists, but the renewal is attached to the wrong account. The document arrived, but only an administrator can open it. Yesterday's report and today's report use different meanings for “active.”
For a growing business, SaaS data migration means moving usable business information into a new system, including the relationships and rules that make it useful. Copying files is one part. Establishing that the new application can support the work is the acceptance decision.
A sensible data migration plan therefore produces evidence at several levels: what moved, how values changed, which records remain connected, and whether the people who rely on them can complete their work. This applies when switching SaaS providers or introducing a custom application alongside existing tools.
Start with the meaning of a field
Column names can look compatible while describing different things. An “owner” might be the person who created a record, the account manager responsible today, or a team assigned to handle the next task. Copying one into another without a decision can change who gets work.
For each important field, write down its source definition, destination definition and transformation rule. Identify who can approve the interpretation. A developer can implement a conversion; the person accountable for the process needs to confirm that it preserves the intended meaning.
A mapping decision might read: “Legacy responsible-team code maps to the new service queue. The importing user must not become the owner by default.” That is proposed documentation, not a rule used in a Lesscode client project.
Keep unresolved values visible. An obsolete status can be retained as historical information, mapped to a reviewed equivalent or held for a decision. Quietly converting everything unfamiliar to the default status hides uncertainty inside production data.
The useful output is more than a spreadsheet pairing column names. It is a record of decisions that another person can understand and that the migration process can apply again consistently.
Count the records, then follow their connections
Counts help establish completeness, provided the comparison has a defined scope. If an export includes archived records and the import deliberately excludes them, the totals should differ. Record the reason and the excluded set rather than making a smaller total look like a successful match.
Keep source identifiers available for reconciliation, even when the destination generates new identifiers. This gives the team a way to trace a questionable destination record to the original and investigate a relationship without relying on a similar-looking name.
Relationships deserve their own validation. A list of customers and a list of service requests can both be complete while the links between them are wrong. Compare the associations that matter to the workflow, including exceptions such as records that legitimately have no parent.
HubSpot's import documentation illustrates the distinction: unique identifiers help update existing records and associate objects, and different import modes have different behavior. Its import-error guidance also describes cases where records import but associations or owner values do not. An import-success message should therefore be read alongside the detailed results.
Those are documented HubSpot behaviors, not universal rules for every SaaS platform. Confirm the destination's actual import semantics before choosing identity and matching rules.
For CRM data migration, resist merging two contacts merely because their names match. Decide what identity means for the business and which identifier the destination supports. A questionable match should become a reviewable exception, rather than an irreversible guess.
Ask an operator to use the migrated data
Consider a hypothetical equipment-rental business moving its bookings into a new application. The import includes customers, reserved equipment, collection times and attached inspection records. No actual migration or test results are being claimed here.
A row comparison can confirm that a booking date arrived. It cannot establish that a branch employee sees that booking in the correct local schedule, that the equipment remains unavailable for another reservation, or that the employee can open the relevant inspection document.
Build a rehearsal around work the team must perform. Have an authorized user find a booking, change a permitted detail and inspect the resulting availability. Include a record that crosses a date boundary or belongs to another branch. Confirm that access remains appropriate: an employee should neither lose necessary access nor gain visibility into unrelated customers.
The rehearsal should use an approved test environment with suitable controls for any real data. Keep outbound messages, billing actions and other external effects under deliberate control. A migration trial should not accidentally send customers a second confirmation.
Write the expected result before running the activity. “The record opens” is a weaker acceptance condition than “the branch user can find the correct booking and its inspection record while another branch's restricted information remains inaccessible.” The latter lets the team recognize a failure and explain why it matters.
The cutover plan needs a policy for new changes
While the team rehearses, the business may continue creating and editing records in the old system. A successful test against last week's export does not account for today's work.
Name the point when the destination becomes authoritative. Decide whether the source will stop accepting changes for a controlled window or whether a supported synchronization process will bring changes across. Document what happens to integrations that continue writing during the transition. Avoid leaving both systems freely editable without a defined reconciliation method.
AWS's cutover guidance describes an ingestion freeze, backup and final synchronization. It also distinguishes rollback before new data arrives from rollback after the new environment has accepted changes. That distinction applies beyond an infrastructure migration: returning people to an old application does not automatically bring their new work back with them.
Before the switch, agree on the conditions for proceeding, pausing or reversing it, and name the person authorized to decide. If the destination has accepted new transactions, a recovery plan must account for those transactions. Restoring yesterday's backup without reconciliation may discard valid work.
A backup is an important recovery resource. It is not, by itself, a complete plan for operating the business after a failed cutover.
Make the acceptance record specific enough to challenge
A migration handover can be concise while remaining useful. Record the source snapshot and destination environment, the transformation version, the reconciliation results and the unresolved exceptions. Add the business activities checked, the people who reviewed them and the decision on whether to proceed.
Keep exceptions separate from successes. A rejected row, an approved omission and a record waiting for manual interpretation are different outcomes. Each needs a disposition and an owner. Otherwise, the total marked “processed” can conceal work that nobody has agreed to finish.
There is no defensible universal answer to how long a SaaS data migration takes. The work depends on export access, volume, relationships, data quality, application behavior and the time needed to resolve exceptions. A rehearsal can reveal those constraints and support an estimate; a generic promise of a weekend move cannot establish them.
Lesscode's API development and integration work includes connecting business systems and building data syncs. When scoping a migration, bring a representative export, the important relationships and a description of the work that must still function afterward. Those materials help define the actual delivery problem.
The final decision belongs with evidence the business can inspect. A migration is ready when the team has an agreed account of the records, the remaining exceptions and the work the destination can support—not simply when the progress bar reaches its end.