Any insight into merging 2 IT Teams (one agile, one traditional) together successfully after M&A exercise?

Proceeding under the assumption that you will be adopting Agile for the newly merged team, the bulk of your energies will obviously be spent in evangelizing and training efforts to compel the traditional team to adopt Agile -- the more established the trad team, the more time and effort you'll expend to win converts.

As an Agile project manager, I've repeatedly encountered foot-dragging and patronizing dismissal of the methodology's roles, rituals, and expectations, primarily from resources with extensive  work histories (whose careers were born and built in a world where waterfall was the only way to manage a project).  This can be a difficult nut to crack, as you need to take care not to alienate these folks, while still compelling them to get with the Agile program.

I recommend that you work closely with each team's leaders so that the traditional lead doesn't feel at risk of being marginalized in deference to the Agile lead (who should be encouraged demonstrate the spirit of servant-leadership by supporting and empowering the traditional lead in their adoption of Agile practices).

Business customers of the traditional team will also need to be educated and inculcated in the ways of Agile project management, as they will likely be far more involved in the process than they were previously.

If you are planning on moving your Agile team over to traditional waterfall management, my advice is simpler and more direct: don't be surprised if you experience attrition with the formerly Agile team, as many resources will seek to maintain an Agile workplace.

Without question I would say paying attention to each other's strengths and weaknesses would be at the top of my list. Each team is going to bring different skills, perspectives, opinions and likely a good idea of what works well and what doesn't. Capitalizing on these differences would be paramount in a successful transition.

Evaluating processes and procedures from both sides should lead to good compromises and discussions going forward. The biggest barrier would likely be loyalty to each person's "side" and not wanting to change.

A traditional approach to IT would provide stability and predictability while lacking adaptions to more current structures such as remote computing and virtualization. The more agile team would be able to bring these new technologies to life adding a much needed boost saving money and helping workers to be more productive.

I'd bet that each team has something to learn from the other. Don't be too quick to dismiss the "traditional" as antiquated or behind-the-times.

There should definitely be some form of integration / collaboration between these two teams but still acknowledging the different strengths of both teams and giving them the room to excel at their strengths and goals.

It may seem basic or "old school" but I always start with MVV, mission, vision, values.  How does the IT team align with the mission of the organization?  What is its purpose?  What are the internal values and how does that align with your mission, vision and values for the IT organization and how does that align with the new organization?  What business problems are you trying to solve?  You'll want to build a single team, which will likely result in turnover from both teams.  That can be a good thing, depending on the strengths and weaknesses of the existing teams.