AI-Powered IT M&A Execution Platform
In most IT separation programs, applications become the primary unit of planning.
We build an application inventory. We assign a disposition to each application. We decide whether it will move, be replicated, replaced, retired, or remain with the seller. We then organize migration waves around those decisions.
This is necessary—but it is not enough.
An application may be ready to move, but that does not mean the business process it supports is ready to move with it.
The real separation boundary is often not the application. It is the collection of interfaces, data feeds, batch jobs, file transfers, shared services, credentials, certificates, and operational dependencies surrounding it.
That is where many separation surprises are hiding.
The application moved. The process did not.
Consider an application approved for migration to the buyer’s environment. The infrastructure is ready. The application is installed. Users can log in. Initial testing succeeds. From the application workstream’s perspective, it may appear ready for cutover.
Then someone runs the complete business process.
The application receives a nightly file from a seller-retained system. It sends completed transactions to another platform through middleware. A scheduled job writes reports to a shared file location. Authentication relies on an account owned by the seller. A certificate for an external connection is registered under the seller’s legal entity.
The application itself may have moved successfully. But it is not operationally independent.
In one migration-wave readiness review, a site was ready to move over a weekend. During final testing, an application failed. The team eventually discovered that it was writing reports to a file share hosted at another site—one outside the migration wave.
The application inventory was correct. The site inventory was correct. The migration plan was detailed.
The dependency connecting them was missing.
Interfaces are rarely owned by one workstream
Interfaces do not fit neatly within a single workstream.
The application team may know the source and target systems. Infrastructure may understand the servers and network paths. Data may know the file contents. Security may own the service accounts and certificates. The business may understand when the interface runs and what happens if it fails.
Each team has part of the picture.
Unless that information is brought together, one interface can appear several times under different descriptions—or not appear at all.
A nightly outbound feed, scheduled file transfer, remote file-share dependency, service account, and daily operational report may all describe the same end-to-end flow. If they are tracked separately, the program may believe it has five items. If nobody owns the whole dependency, the program may track nothing that proves the flow will work after separation.
An interface inventory is more than a list
Creating an interface inventory is a good start. Simply collecting interface names is not enough.
For separation execution, every interface should answer a practical set of questions:
- What are the source and target systems?
- What information moves through the interface, and how?
- How frequently does it run, and which business process depends on it?
- Who owns it today, and which transaction perimeter contains each endpoint?
- What is its separation disposition?
- Will it continue temporarily under a TSA?
- Does it require a new connection, account, certificate, firewall rule, or vendor agreement?
- How will it be tested, and what evidence will prove it works in the target environment?
In a large environment, those answers may be distributed across architecture documents, integration platforms, application support teams, network records, scheduler tools, vendor configurations, and individual knowledge.
Interface discovery cannot be treated as a one-time spreadsheet exercise.
Application disposition must drive interface disposition
When an application disposition is decided, every connected interface should be reviewed.
An application moving to the buyer may require an interface to be repointed, rebuilt in the buyer’s integration platform, continued temporarily across environments, replaced with a manual process, included in a TSA, retired, or supported through a temporary extract.
The interface disposition should not be assumed from the application disposition.
Two applications may both move to the buyer in different migration waves. The interface between them may need to cross environments temporarily. If one remains with the seller, a new data-sharing arrangement may be required. If one is replaced, its interfaces may still be needed until historical processing and reconciliation are complete.
These are execution decisions. They affect architecture, security, testing, cutover, TSA scope, cost, and operational support.
Migration waves create temporary architectures
Separation teams often focus on the final target architecture. Most large separations do not reach it in one cutover.
Applications, users, sites, infrastructure, and data move in waves. During that period, the organization operates through a temporary architecture. Some systems remain with the seller. Others are with the buyer. Some are under TSA coverage. Others have exited. Interfaces cross security boundaries that did not exist before the transaction.
That temporary state can be more complex than either the current or target environment.
Every migration wave should therefore be reviewed for:
- Interfaces entering or leaving the environment
- Dependencies on applications moving in later waves
- Shared file locations and integration-platform components
- Firewall, network, service-account, credential, and certificate changes
- External endpoints and scheduling dependencies
- Monitoring and support ownership
A wave is not ready because every application has a green status. It is ready when the required business flows can operate across the temporary architecture after cutover.
Testing individual applications is not enough
Application testing often confirms that users can log in, execute key functions, and access the expected data. Separation testing must go further.
The program needs to test business flows across systems and environments. Can an order move from the front-end application through fulfillment and invoicing? Can manufacturing receive the required master data? Can finance generate downstream reports? Can the application send files to an external partner using the new certificate and network route?
A successful screen test does not confirm a successful interface.
Testing should also prove what happens when an interface fails: who receives the alert, which team restarts the job, whether the buyer can access the monitoring tool, and whether the issue can be resolved without relying on the seller.
An interface is not truly separated until it can be operated and supported within the new ownership model.
TSA exits depend on interfaces too
TSA exit planning frequently focuses on applications and infrastructure services. Interfaces can become an overlooked source of continued dependency.
A buyer may migrate an application and believe it is ready to exit the related TSA. But the application may still rely on the seller’s middleware, managed file-transfer service, scheduler, certificate, service account, network connection, or support team.
The visible application has moved. The underlying service has not.
Before confirming a TSA exit, the program should demonstrate that required interfaces have been rebuilt, redirected, retired, or transferred—and that the new operating team can support them.
A completed task or green status is not sufficient. The decision should be supported by test results, operational acceptance, support ownership, and confirmation that no hidden seller dependency remains.
Manage the flow, not just the asset
Applications remain central to separation planning. They provide a practical way to organize scope, ownership, cost, and migration activity. But an application is only one part of a business process.
The business does not operate through isolated applications. It operates through information moving between applications, people, sites, vendors, and platforms.
A strong separation program should connect four things:
- The application disposition
- The interface disposition
- The migration-wave plan
- The end-to-end business process
When those elements are managed together, teams can see whether an application will simply move—or whether it will actually work after it moves.
Because in an IT separation, moving the application is only part of the job.
The separation boundary is where its dependencies begin.