System Migration Discovery: What to Establish Before You Move

The short answer

Large system migrations rarely fail on data. They fail on the processes nobody documented, discovered during user acceptance testing when the timeline has no room left.

The pattern is consistent. Requirements are gathered from process owners and existing documentation. The new system is configured against that picture. Testing begins, and the people who actually run the work start describing cases the configuration does not handle: the exception path that carries a third of volume, the manual step that bridged two systems, the approval that happens outside any system, the regional variant nobody flagged.

At that point the organization has three options, all expensive. Extend the timeline, build custom handling for cases that should have been in scope, or go live knowing a portion of the work will run outside the new system on day one.

The third option is the most common and the most consequential, because the workarounds that form in the first months become permanent.

Establishing the real current state before scoping is the intervention, and it is cheaper than any of the three alternatives.

Key takeaways

• Migration overruns concentrate in processes that were never documented, not in data conversion.
• The exception rate in the current process determines how much of the configuration scope is missing.
• Process owners describe the intended process. The people handling exceptions describe the one being migrated.
• Regional and business unit variants are the single largest source of late-discovered requirements.
• A migration is the best opportunity an organization gets to remove steps, and the one most often wasted.
• Discovery for a migration is scoped and time-bound, which makes it different from a general transformation diagnostic.

What a migration needs the current state to answer

Six questions. If any lacks an answer, the configuration scope is being drawn against an assumption.

1. What proportion of volume follows the documented path?

This number governs everything downstream. If a quarter of cases are exceptions, a configuration built for the documented path handles three quarters of the work and none of the reason the migration was difficult.

Most organizations cannot state this number for the processes they are migrating.

2. What are the exception types and how often does each occur?

Not a list of possible exceptions, a distribution with frequencies. Configuration decisions depend on whether an exception occurs weekly or twice a year, and the two get treated identically when nobody has the data.

3. Where does the process vary by market, business unit or customer segment?

Variants are the largest source of requirements discovered during testing. A process that looks like one process on the org chart is frequently five, and the differences were adaptations made locally over years.

The distinction that matters is between variants that exist for a real requirement, such as a tax rule or regulatory obligation, and variants that are inherited. The first must be configured. The second should be removed during the migration, which is the best opportunity the organization will get.

4. Which steps happen outside any system?

Approvals over chat, spreadsheets that bridge two systems, manual enrichment, checks performed from memory. None of these appear in the system being replaced, so none of them appear in a migration scope derived from that system.

They are, however, load-bearing. A new system that does not accommodate them either breaks the process or is bypassed.

5. Which steps exist for a reason that no longer holds?

Migrations are the one moment where removing a step is organizationally possible, because everything is changing anyway. Controls added after resolved incidents, duplicate approvals, validations catching upstream errors, reporting nobody reads.

Carrying these into the new system makes them permanent for another decade.

6. Who actually owns each decision?

The org chart names an owner. In practice, the decision may be made by someone else, or by nobody, which is why the case waits. Configuring approval routing against the documented owner reproduces the delay in a new system.

Why the standard requirements process misses these

It asks the wrong people

Requirements gathering typically involves process owners, functional leads and superusers. They understand the intended process well and are the right people to ask about design intent.

The exception path is handled by people further from that group, and they are rarely in the room. That is not an oversight in the abstract, it is a consequence of who gets invited to a requirements workshop.

It reads the system being replaced

Extracting current-state requirements from the outgoing system captures what that system recorded. The compensating work that grew around its limitations is invisible by construction, and that compensating work is frequently the reason the migration was commissioned.

It runs on a project clock

Requirements phases are time-boxed against a go-live date. Depth loses to coverage of the documented scope, and the questions that would surface variants take longer than the schedule allows.

The timing is adversarial

Requirements gathering happens when the business is being asked to contribute time to a project that will disrupt them. Participation is thin, the people with the most detailed knowledge are the busiest, and the gaps surface later when the cost of addressing them is highest.

Migration discovery window

Cost of finding a gap, by phase

The same gap costs a decision in the first row and a workaround in the last. Nothing about the gap changed, only when it was found.

Running discovery inside a migration timeline

Migration discovery is not a general transformation diagnostic. It has a defined scope, a hard deadline and a specific output, which makes it a different exercise.

Five properties of one that works.

Scoped to the processes in the migration. Not the function, the processes. A CRM migration touches a defined set of workflows, and discovery outside them is noise the project cannot use.

Covers the exception handlers. The population has to include the people who work the variants, in every market and business unit in scope, not a sample selected by process owners.

Asynchronous. Requirements phases compete with business as usual for calendar time, and the people with the most useful knowledge have the least availability. A discovery method that requires scheduling is a discovery method that will sample.

Produces a variant catalogue. For each variant: what requirement produces it, whether that requirement still holds, and who would have to agree to remove it. That catalogue is the input to the standardization decision, which is the highest-value decision in most migrations.

Outputs into the configuration scope directly. Findings that arrive as a report require a translation step the project has no time for. They need to arrive as requirements with frequency, affected population and disposition attached.

The standardization decision

Every migration presents the same choice and most organizations defer it.

Configure the new system to accommodate the existing variants, or standardize the variants and configure one process.

Accommodating is faster to agree and considerably more expensive over the life of the system. Each variant multiplies configuration, testing, training, documentation and future change effort. A process configured five ways costs roughly five times as much to modify later.

Standardizing requires business unit agreement, which requires evidence at their level rather than at the aggregate. A unit asked to give up its version needs to see what that version costs and what the standard version delivers for them specifically.

That evidence is a discovery output. Without it, the standardization conversation has no basis and the default is to accommodate.

Where Horizon fits

Horizon is an AI-powered continuous discovery platform. In a migration context it produces the current-state picture the configuration scope depends on, within the window the project has.

Discovery Cycles run AI-led interviews asynchronously across every role, market and business unit touched by the migration, without requiring calendar time from teams already carrying the project. The conversations adapt to each role and follow up on gaps, which is how exception paths and undocumented steps surface. The Process Library structures the result into navigable documentation organized by process, which is what makes variant comparison across units possible. The Insights Dashboard ranks findings by impact and effort with traceability to source, and the Initiatives Dashboard converts them into scoped items with owners.

Despegar, the leading travel technology company in Latin America operating in more than 20 countries with over 3,900 employees, used it ahead of a CRM migration.

The starting condition was the one this guide describes. Commercial operations were manual and poorly integrated. Information was dispersed across different tools and systems. Teams duplicated tasks, managed inconsistent data and made decisions with delays. The migration needed Product, Commercial, Finance and HR aligned, with roles and standards defined, and none of that existed in a documented form.

Horizon gathered input from more than 170 collaborators across Media Sales and HR, analyzing over 124 hours of conversations. In under four weeks it delivered insights on campaign activation, reporting, billing and collections, plus a dashboard of 45 initiatives prioritized by impact and effort, with concrete recommendations to guide the CRM migration and strengthen collaboration across the four functions. Average satisfaction was 9.1 out of 10, and the comparison against the manual approach was 12 months against under four weeks.

As one participant described it, interviewing 200 people in two weeks would have been impossible manually, and the findings obtained would not have come from a form.

The timeline point is the operative one for migrations. A current-state picture that takes 12 months is not available to a project with a go-live date. One that takes four weeks fits inside the requirements phase.

That is one engagement under specific conditions rather than a projection for any organization.

Pre-migration checklist

1. Can you state what proportion of volume follows the documented path, per process in scope?
2. Do you have an exception catalogue with frequencies?
3. Have you catalogued the variants by market and business unit?
4. For each variant, do you know which requirement produces it and whether it still holds?
5. Do you know which steps happen outside the system being replaced?
6. Have you identified steps that should be removed rather than migrated?
7. Do you know who actually makes each approval decision, as distinct from who is named?
8. Have the exception handlers contributed to requirements, not only process owners?
9. Is there a standardization decision on the record, with evidence at business unit level?
10. Does each discovery finding arrive as a requirement with frequency and disposition, or as a report?
11. Do you know what will run outside the new system on day one, and is that deliberate?

Question 11 is the one to answer honestly before go-live rather than after.

Common mistakes

Deriving requirements from the outgoing system. It records what it recorded. The compensating work around its limitations is the part that matters.

Treating variants as noise. They are the largest source of late requirements, and some of them encode real obligations.

Migrating steps that should be removed. The migration is the one moment removal is organizationally possible. Carrying them makes them permanent.

Sampling the requirements population. A sample selected by process owners reproduces the documented process.

Deferring the standardization decision. Deferring is a decision to accommodate, made without acknowledging the cost.

Finding the gaps in UAT. The same gap costs a configuration decision before scoping and a custom build under deadline in testing.

FAQ

What should you do before an ERP or CRM migration?

Establish the real current state of the processes in scope: the exception distribution, the variants by market and business unit, the steps that happen outside the system being replaced, and the steps that should be removed rather than migrated. Requirements derived from the outgoing system and from process owners will miss most of that.

Why do system migrations run over budget?

Most commonly because requirements missed processes nobody had documented, and those surface during user acceptance testing when the timeline has no room. The cost of addressing a gap rises sharply by phase: a configuration decision before scoping becomes a custom build under deadline in testing.

Should you standardize processes before or during a migration?

During, in most cases, because the migration is the moment when changing the process is organizationally possible. Standardizing afterward requires a separate change programme that rarely gets funded. The prerequisite is evidence at business unit level, since units asked to give up their version need to see what it costs them specifically.

How long does pre-migration process discovery take?

It depends on the number of processes, markets and business units in scope. The practical constraint is that it has to fit inside the requirements phase, which means a method that requires scheduling interviews across a distributed population will sample rather than cover.

Who should be involved in migration requirements gathering?

Process owners and functional leads for design intent, and the people who handle exceptions for the process being migrated. The second group is usually absent from requirements workshops and holds most of the information that surfaces later in testing.

What is the biggest risk in a system migration?

Going live with a portion of the work running outside the new system because the configuration did not accommodate it. The workarounds that form in the first months tend to become permanent, which reproduces the condition the migration was meant to resolve.

Find it now or find it in testing

Every gap in a migration scope gets found eventually. The variable is when, and the cost difference between the two ends of that range is large.

A current state established from the people who run the work, before the configuration is drawn, is the cheapest version of a conversation the project is going to have regardless.

See it. Fix it. Scale it.

See Horizon in action.