Everything is green—so why isn’t the migration wave ready?

A few days before a migration wave, the status report often looks reassuring.

Applications are green. Infrastructure is green. End-user computing is green. Network is green. Testing is green. The site team confirms that preparations are complete. The PMO reports that the wave is on track.

Then someone asks a simple question:

Can the business actually operate after the migration?

Suddenly, the conversation changes.

The site may be ready. The desktops may be ready. The applications may have passed their individual checks. But that does not necessarily mean the migration wave is ready.

This is one of the recurring problems in large IT separations. Readiness is measured within workstreams, while business operations depend on connections across workstreams.

Everything can be green independently—and still fail collectively.

A completed schedule is not the same as operational readiness

Migration plans are usually detailed. They contain hundreds, sometimes thousands, of activities covering build, migration, testing, communications, cutover, validation, and hypercare.

The problem is rarely the absence of a plan.

The problem is that most plans track whether activities were completed. They do not always prove that the technology environment will work as an integrated whole after the cutover.

An infrastructure team may confirm that a server has been migrated. The application team may confirm that the application is available. The EUC team may confirm that desktops have been reimaged. The network team may confirm that connectivity tests were successful.

Each statement may be accurate.

But can the reimaged desktop launch the application? Can the application reach its database? Can it write to the required file share? Can the user authenticate? Can the business print, exchange data with another system, and complete the full process?

Those questions cross workstream boundaries. That is where many migration risks remain hidden.

The site migrated—but its dependency did not

In one situation, a site was included in an upcoming migration wave. The local infrastructure had been assessed, users were identified, devices were prepared, and the applications associated with the site were included in the readiness reporting.

Late in the process, the team discovered that one of the applications used at the site was writing files to a file share hosted at another site.

That second site was not part of the same wave. It was scheduled to migrate later.

On paper, the application belonged to the first site. The file share belonged to the second. Both inventories were correct when viewed separately.

Operationally, however, the two sites were connected.

If the first site had been migrated without addressing that dependency, the application might have launched successfully while failing when users attempted to save, retrieve, or process files. The application team could have reported green. The site team could have reported green. Yet the business process would have been disrupted.

The risk was not in either inventory. It was in the relationship between them.

The desktop was ready—but its applications were not

A similar issue appears frequently in end-user computing.

The EUC team may successfully reimage a desktop, join it to the new domain, apply security policies, install the standard software package, and confirm that the user can log in.

From an EUC perspective, that device is ready.

But some desktop applications may still point to the old environment. There may be hard-coded server names, legacy URLs, old database connections, mapped drives, local configuration files, browser bookmarks, scripts, plug-ins, or integrations that were not updated.

The desktop migration succeeds technically, but the user cannot perform the job.

This becomes even more complicated when application ownership and packaging ownership sit with different teams. The application team assumes EUC will update the desktop configuration. The EUC team assumes the application package provided to them is current. Testing may cover whether the application opens, but not whether it connects to the correct environment or completes an end-to-end transaction.

Everyone has completed their assigned task. The failure sits between the assignments.

Green workstreams can still produce a red business outcome

Large separation programs are structured into workstreams for a good reason. Applications, infrastructure, network, cybersecurity, identity, EUC, data, contracts, sites, and business readiness require different expertise.

The challenge begins when the workstream becomes the boundary of readiness.

A migration wave is not a collection of independent technical completions. It is a temporary operating model that must work at a specific moment in time.

Consider a few common examples:

• An application is migrated, but its service account remains in the seller’s identity environment.
• A server is available, but the firewall rule needed by an upstream interface has not been implemented.
• Users are migrated, but the authentication method for a critical SaaS application still relies on the seller’s single sign-on.
• A contract has been assigned, but the software license keys cannot be transferred until the vendor processes the new legal entity.
• An ERP environment is ready, but a smaller operational application still sends data to the legacy ERP instance.
• A printer is visible on the network, but the print server or label-printing application remains in the old environment.
• Data has been copied, but scheduled jobs, reports, interfaces, or downstream extracts still reference the original location.
• Testing is complete for individual applications, but no one has validated the full business process across those applications.
• A site is declared ready, but a local device, scanner, manufacturing interface, or shared drive was never included in the central inventory.

None of these issues is particularly exotic. Most are ordinary dependencies that were either not captured, not connected to the wave, or not owned through closure.

What does “green” actually mean?

One of the first questions a migration leader should ask is: What evidence is required before something can be called green?

In many programs, green means the workstream lead believes the activity is on track. In others, it means tasks are complete in the project plan. Sometimes it means testing has started and no major issues are currently known.

These definitions are not equivalent.

A more useful readiness status should answer three questions:

1. What has been completed?
2. What evidence proves it?
3. What other components depend on it?

Without those answers, green is often an opinion rather than a readiness position.

For example, “desktop build complete” is not sufficient evidence that users are ready. The evidence may need to show that the correct applications are installed, configurations point to the target environment, authentication works, required file shares are accessible, peripherals operate, and the business user has completed a representative transaction.

Likewise, “application testing complete” may mean little if the test covered only application availability and not its interfaces, data flows, file transfers, reports, batch jobs, and user access from the migrated desktop.

Green should represent an executable condition—not simply task completion.

Dependencies must be tied to the migration wave

Most programs maintain dependency logs. The issue is that the dependency log often sits beside the migration plan rather than inside it.

Dependencies are recorded as statements:

• Application A depends on Database B.
• Site X uses File Share Y.
• Interface C connects to the seller environment.
• Users require access to SaaS Platform D.

But when the migration waves are created, those relationships may not be recalculated against wave timing.

A dependency only becomes actionable when it is connected to a date, a wave, an owner, a validation method, and a consequence.

If Site X moves in Wave 2 and File Share Y moves in Wave 5, the program needs a deliberate solution. That may involve moving the file share earlier, keeping temporary connectivity, copying the required data, changing the application configuration, or moving the application to a different wave.

What should not happen is discovering the relationship during cutover.

The same logic applies to users and applications. If desktops are reimaged during one weekend but a required application is not ready until the following month, the program must decide how those users will operate in the interim. It cannot remain an unspoken assumption between the EUC and application teams.

Testing must follow business transactions, not organization charts

Testing is often organized the same way as the program: by workstream or technology component.

Infrastructure tests infrastructure. Application teams test applications. EUC tests desktops. Network teams test connectivity.

These checks are necessary, but they do not prove business readiness.

A real business transaction rarely stays within one workstream. A user may authenticate through the new identity environment, open an application on a reimaged desktop, retrieve information from a database, write a document to a shared location, trigger an interface, generate a report, and send an output to another party.

That entire chain must work.

End-to-end testing should therefore follow critical business processes across technology components. It should also be aligned to the exact population and configuration included in the wave.

Testing an application from an administrator’s device is not the same as testing it from the desktop that a user will receive on Monday morning.

Testing a file share from the network team’s account is not the same as proving that the migrated users have the correct access.

Testing that an interface transmitted one file is not the same as confirming that the downstream system processed it correctly.

The closer testing gets to the actual post-migration operating condition, the more useful the readiness status becomes.

Readiness needs a wave-level owner

Workstream leads should remain accountable for their areas. But someone must own the readiness of the wave as an integrated outcome.

That role is not simply collecting status updates.

The wave owner must challenge cross-workstream assumptions, identify dependencies that cross migration dates, confirm that evidence exists, and make sure open risks are translated into operational decisions.

The discussion should move beyond whether the application, infrastructure, and EUC teams are green. Instead, it should ask:

• Can every in-scope user perform the critical business processes after cutover?
• Are all dependencies available in the target state or supported through an approved interim solution?
• Have exceptions been tested under the conditions that will exist after migration?
• Are unresolved items clearly owned with a decision deadline?
• Is the business prepared for the remaining risks?
• What evidence supports the recommendation to proceed?

A wave should not be approved because most workstreams submitted green status. It should be approved because the combined environment has been shown to be operationally ready.

The goal is not to eliminate every risk

No major migration wave will reach zero risk. There will be defects, exceptions, late changes, and issues that require hypercare.

The objective is not perfection.

The objective is to know what is ready, what is not ready, what depends on what, and what will happen if an unresolved item fails.

That allows the program to make an informed go/no-go decision.

A known issue with a tested workaround may be acceptable. An unknown dependency hidden behind multiple green workstream reports is far more dangerous.

Good migration governance does not make risk disappear. It makes risk visible early enough to manage.

From status reporting to evidence-based readiness

The question is not whether the project plan is detailed enough. Most large programs already have detailed plans.

The question is whether the plan, inventories, dependencies, testing results, risks, decisions, and evidence are connected around the migration wave.

When that information remains spread across workstream trackers, spreadsheets, emails, meeting notes, testing tools, and presentation decks, the program spends enormous effort reconciling status—and still may not see the operating risk.

A migration wave is ready when the technical components, business processes, dependencies, people, and evidence come together as one executable picture.

Until then, green may simply mean that each team completed its part.

And in IT M&A, completing the parts is not the same as making the whole work.