When two engineering teams become one, whether through an acquisition or a reorganization, the conversation tends to go straight to tooling. Whose pipeline, whose framework, whose ticketing system, whose branching model. I think that is the easy part, and also the part most likely to go wrong if it is decided first. Here is what I think matters more.
Protect what made the smaller team work
Two teams are rarely the same size, and the smaller one knows it is the one being absorbed. Everything it did well was done with its own tools and habits, and the fastest way to lose those is to declare a winner in week one. The habits go, the people who valued them go a few months later, and the organization keeps the tooling and loses the reason it wanted the team.
So my first instinct is to find out what the smaller team is proud of and protect it, visibly, before any standardization conversation starts. The team should hear that its way of working is being studied, not replaced.
Share the few things that must be shared
Some standards genuinely have to be common. I think the list is shorter than most organizations assume: how code reaches production, how changes are reviewed, how security is handled, and how incidents are run. Those are shared because the consequences are shared. Nearly everything else, from editor settings to the shape of a sprint, can stay different for a long time without costing anything.
I would agree the short list early, and I would be willing for either team's version to win each item, chosen on merit rather than on size. A merged team that sees the larger side lose a few decisions learns that the process is real.
Put both teams on one real thing
Documents and all-hands do not integrate teams. Work does. I think the single most effective move is a real piece of work, with a real deadline, staffed from both sides, where the people have to depend on each other to ship. The friction that surfaces is the friction that matters, and it surfaces in a context where there is a reason to resolve it.
Do not decide the hard things in the first month
The first month is when everyone knows the least and feels the most pressure to show progress. I think the decisions that are easy to make and hard to reverse, like which codebase survives or which architecture the product will have in three years, should be deliberately deferred. Say when they will be made and what will be learned first. Deferral with a date is a decision. Deferral without one is drift.
Listen for the phrase
There is one phrase I listen for in a merged team: the way we used to. Said with affection, it is history. Said with resentment, six months in, it means the integration stalled and the smaller team is still a separate team that happens to share an org chart. That is the point at which the tooling decision, whatever it was, stops mattering, because the people have already decided.
None of this is fast. Bringing two teams together is a year of work that is mostly about people and only occasionally about systems. I think the organizations that get it right are the ones that plan for the year and not for the migration.
Photo source: https://photos.robertstowe.com/cumberland-island