Navigating the Cloud After the Handshake: An Architect’s Guide to Post-M&A Azure Migration

The ink is dry, the deal is done. Your company has just acquired another, and now the real work begins. As a solutions architect, I’ve seen this scenario play out countless times: two disparate IT landscapes, often with varying levels of maturity and documentation, suddenly need to become one cohesive, cloud-powered entity. The task is daunting, especially when the acquired company lacks an updated assessment and the mandate is clear: all roads lead to Azure.

This isn’t just about moving data; it’s about strategic alignment, minimizing disruption, and leveraging the cloud’s full potential. So, let’s break down how an experienced architect approaches this multi-faceted challenge, focusing on databases, SharePoint, and critical replication and storage strategies within Azure.

Phase 1: The Crucial Discovery – Because You Can’t Migrate What You Don’t Know

Before you even think about “moving,” you need to know. The lack of a recent assessment from the acquired entity is a red flag, but also an opportunity. This isn’t just a discovery; it’s an archaeological dig.

• Database Inventory: Deploy Azure Migrate as your central command. It’s excellent for discovering SQL Servers and providing initial readiness assessments. But don’t stop there. Supplement with network scans and third-party tools (or even manual detective work) to unearth all database instances: Oracle, MySQL, PostgreSQL, MariaDB, even Access databases hiding on file shares. For each, document the version, size, dependencies, and most critically, its business criticality (RTO/RPO).
• SharePoint Reconnaissance: SharePoint migrations are rarely “just move the files.” Use the SharePoint Migration Assessment Tool (SMAT) to get a clear picture of their farm. This will reveal versions, content volume, and highlight the notorious custom farm solutions, custom master pages, and legacy workflows that will be your primary challenges. Interview users to understand how they actually use their sites. Is it a document dump or a critical business process hub?

This initial phase is not glamorous, but it’s the bedrock. Skimp here, and you’ll pay for it tenfold in later phases with unexpected roadblocks and costly rework.

Phase 2: Strategic Planning – The “6 Rs” and Beyond

With your inventory in hand, it’s time to plot the course. This is where the strategic “6 Rs” of cloud migration come into play, but with an Azure-specific lens.

Database Strategy: Rehost, Replatform, Rearchitect

1. Rehost (Lift & Shift): SQL Server on Azure VMs.
   • When to Use: You need to exit a datacenter fast, or the application is a legacy beast that absolutely demands OS-level control, a specific ancient SQL version, or complex third-party tools at the OS layer.
   • Architect’s Take: The quickest path, but you inherit the patching, backup, and management overhead. It’s a stepping stone, not usually the final destination for cloud optimization.
2. Replatform (Modernize): Azure SQL Managed Instance & Azure Database for Open Source.
   • When to Use: This is your sweet spot for most existing databases.
     • Azure SQL Managed Instance: The gold standard for SQL Server lift-and-shift with minimal code change. It offers near 100% compatibility with on-premises SQL Server, supporting instance-level features like SQL Agent and cross-database queries. This is typically my first recommendation for existing SQL Server workloads.
     • Azure Database for MySQL/PostgreSQL/MariaDB: A direct replatform for open-source databases. Offloads the patching and HA burden to Azure.
   • Architect’s Take: Maximum cloud benefits (managed service, auto-patching, HA built-in) with minimal application refactoring. Excellent ROI.
3. Rearchitect (Cloud-Native): Azure SQL Database & Azure Cosmos DB.
   • When to Use: For new applications, or when you’re deeply refactoring an existing application to be truly cloud-native, scalable, and modular.
     • Azure SQL Database: For highly scalable, cloud-first relational applications. Consider Serverless for unpredictable workloads or Hyperscale for massive databases.
     • Azure Cosmos DB: When your application demands global distribution, multi-model flexibility (document, key-value, graph), and guaranteed single-digit millisecond latency. Ideal for IoT, mobile, and highly distributed web applications.
   • Architect’s Take: Highest effort, highest reward. This is long-term strategic positioning, unlocking true cloud elasticity and global reach.

SharePoint Strategy: Modernize to SharePoint Online

• Primary Target: SharePoint Online (part of Microsoft 365).
  • Architect’s Take: Avoid rehosting a full SharePoint farm on IaaS unless there’s an extreme, temporary constraint. The future is modern SharePoint Online, integrated with Microsoft Teams and the Power Platform.
  • Modernization is Key: Plan to flatten complex subsite hierarchies into Hub Sites. Crucially, legacy farm solutions (WSPs) will not work in SharePoint Online. They must be rebuilt using the modern SharePoint Framework (SPFx) or replaced by out-of-the-box features and Power Platform solutions. SharePoint Designer workflows must become Power Automate flows.
  • Archiving: This is an excellent opportunity to retire or archive inactive sites. Don’t migrate junk!

Phase 3: Execution – The Art of the Move

This is where planning meets reality. My mantra: pilot, communicate, wave.

• Pilot Everything: Seriously. Pick a low-risk, non-critical database and a simple SharePoint site. This first wave validates your tools, processes, and communication strategy. You’ll uncover unforeseen issues here, saving you pain on mission-critical systems.
• Communication is King: Especially for SharePoint. Users will notice changes. Inform them about timelines, content freezes, and where to find their stuff post-migration.
• Database Migration Tools:
  • Azure Database Migration Service (DMS): This is your best friend for online migrations (near-zero downtime). DMS orchestrates continuous data synchronization from source to target, allowing you to cut over in minutes. Essential for critical production databases.
  • Native Tools: For less critical systems, a simple backup/restore (for SQL Server) or BACPAC/DACPAC files (for Azure SQL Database) can be sufficient.
• SharePoint Migration Tools:
  • SharePoint Migration Tool (SPMT): Free, robust for basic content moves (SharePoint Server 2013+).
  • Third-Party Tools (e.g., ShareGate): Invest in these for complex migrations involving restructuring, metadata management, and detailed reporting. They’ll pay for themselves in reduced manual effort and fewer headaches.

Phase 4: Post-Migration – Optimize, Govern, and Secure

The cutover is not the finish line; it’s the start of the next race.

• Optimization: Right-size your database tiers. Don’t pay for what you don’t use. Use Azure Monitor and Query Performance Insight to analyze actual usage and adjust. Implement Azure Hybrid Benefit and Reserved Instances to control costs.
• Governance: Crucial for SharePoint Online. Define clear policies for site creation, external sharing, and data lifecycle management using Microsoft Purview for data classification and retention.
• Security: Leverage Microsoft Defender for Cloud. Ensure encryption at rest and in transit. Configure Azure AD and RBAC for all database and SharePoint access.
• Replication for Resilience:
  • For Azure SQL DB/Managed Instance: Implement Auto-Failover Groups for cross-region disaster recovery and readable secondaries for read scale-out.
  • For SQL Server on Azure VM: Continue with SQL Server Always On Availability Groups.
  • For Azure Cosmos DB: Simply add regions to achieve global distribution for both low-latency access and built-in disaster recovery.
• Storage Redundancy – When GZRS Shines:
  • For your most mission-critical data in Azure Storage (backups, core application data), use Geo-Zone-Redundant Storage (GZRS). This provides the ultimate protection by synchronously replicating data across three Availability Zones within a region for high availability, and then asynchronously replicating it to a paired secondary region for disaster recovery. It’s the highest durability, but also the highest cost, so use it judiciously. For less critical data, ZRS (intra-region HA) or GRS (inter-region DR) might suffice.

In the board below you can have a better comprehension of what strategy to use:

The Architect’s Mandate

M&A is disruptive by nature. Your role as a solutions architect is to bring order, clarity, and strategic direction to the IT integration. By systematically assessing, planning, executing, and then optimizing within Azure, you not only integrate disparate systems but also lay the groundwork for a more agile, resilient, and cloud-optimized future for the combined entity.

This journey is complex, but with the right phased approach and a deep understanding of Azure’s capabilities, it’s a journey you can navigate with confidence.