Its the scoping that determines if the integration will fail

Everyone in the planning meeting will agree that it will be faster to just lift and shift everything over.

A 30-minute workshop for the technical leader asked to help plan the integration.

It looks obvious

Your company just closed on their first or second acquisition and you were just invited to the first of several integration planning sessions to figure out how to migrate the data and custom apps over.

What do you ask first?

The not so secret about these types of conversations is that the people asking these questions: the C-suite, project managers, finance, etc. are looking at the integration of the acquisition through the lenses of their departments or logical business streams.

It makes sense assuming everything fits into a specific line of business.  As a result, the quickest path forward is to take everything and bring it into your company.

Lift and shift

Two things tend to get missed

The common infrastructure that everyone depends on

Since common infrastructure doesn't belong to any one business stream, nobody in the planning session thinks to raise it. It also doesn't really come up until your are midway through the integration work when you need to wire everything up.

Things like:

• Missed DNS changes
• Misconfigured APIs/web gateways
• Hardcoded dependency on centralized identity provider
• Lost access to dependencies (e.g., databases, services)
• Post-cutover scaling issues (e.g., payroll, quarterly financials, benefits enrollment)

Every company has developed their own approach to solving common IT challenges.

Theirs and yours will not be the same, and the differences don't show up until you try to move something.

Something that would have been simple to fix pre-acquisition turns into an operational, organizational, and cultural mess.

TL;DR:

Questions aimed only at the tech stack being migrated will miss both of these common pitfalls.

What does this mean for your plan?

• Contrary to what the rest of the integration team will tell you, lifting and shifting will not work
• You will have duplicate functionality to account for (and extra costs to support it going forward)
• You will have dependencies between different business areas that require coordination nobody has accounted for

This is where assumptions have to be challenged before a realistic plan can come together.

The types of questions we will cover

The typical questions that tend to be asked focus more on what the other side has in order to figure out how to migrate everything over. These types of questions have a place in scoping out the migration, but don't really get everything.

Before you can get to this point, you need to know if it is even needed, and if so, how. That is what this webinar will cover:

1. Are these components necessary given what already exists on your side and the purpose of the acquisition?
2. What do employees and customers interact with, how, and how should that behavior change post-integration?
3. What support systems do they have in place, and what equivalent systems do you have?
4. How are their systems managed today, and what has to change to support moving them into your ecosystem?

What these questions will give you

• Clarity on the actual scope of work
• Shorter list of components to migrate, plus the integration pieces that have to be accounted for
• What user experience to expect, how it could change, and what to tell users at cutover
• Whether your systems can handle the new data
• What has to change in your change management process
• Realistic timelines, based on updated path-to-production guidance

Who it is for?

If your company just closed on an acquisition, or is about to — and you're one of the following:

• An architect or senior technical leader responsible for defining, and possibly leading, the technical integration work
• The managing director or VP responsible for the technical workstreams
• The project manager leading the technical breakdown of those workstreams

If your company already has an M&A integration playbook and a team that runs it, you can safely skip this workshop.