Cloud migration - Architect View

This blog offers insights into cloud migration from an architect’s perspective, focusing on strategies for seamless migration through proper planning and risk mitigation.

3/11/20253 min read

high angle photography of blue and white cloudy sky
high angle photography of blue and white cloudy sky

Cloud Migration

Migrating or hosting applications from on-premises data centers to public cloud providers like AWS, Azure, GCP, Alibaba, Oracle, or IBM Cloud is a common but complex process.

While cloud providers offer extensive documentation and resources, each environment is unique, often presenting real-world challenges. This blog, from an architect’s perspective, explores both common and specific migration hurdles.

Whenever possible, modernizing applications before migration is the preferred approach. This includes refactoring software, transitioning to advanced platforms (PaaS), and optimizing workloads for improved scalability, performance, and cost efficiency.

Choosing Service Providers :

The selection of one or more public cloud providers—such as AWS, Azure, GCP, Alibaba, Oracle, or IBM Cloud—is a strategic decision made by an organization’s top executives. This choice is driven by various factors, including cost, business objectives, and the existing IT strategy.

Rather than comparing cloud providers and their benefits (as extensive resources are already available online), this blog focuses on the key considerations architects and engineers must address for a successful migration.

A well-planned approach ensures a smooth transition and effective cost allocation for large-scale projects. The process begins with analyzing the application inventory—identifying which applications to migrate, assessing their compatibility with the new infrastructure, and resolving potential challenges before the transition.

Pilot Application:

Selecting the right application for migration is critical, as it acts as a testbed for assessing the organization’s ability to adapt to a cloud platform. It also helps identify gaps and refine processes for a smoother transition.

For an initial migration, choosing a simple application with minimal dependencies is ideal. This minimizes complexity, allowing teams to focus on validating infrastructure and processes before handling larger, more interconnected workloads.

Migrating a highly dependent application too soon can introduce compatibility issues at various levels, potentially disrupting the primary goal—testing and validating the cloud environment effectively.

Organisations Architectural Requirements/Decisions:

Just as selecting a cloud service provider is a strategic decision, each organization follows its own approach to modernizing infrastructure—whether to enhance customer experiences, upgrade technology, optimize costs, or align with ESG goals to reduce carbon emissions. Designing a cloud solution that meets these objectives requires a clear understanding of architectural requirements.

Some organizations adopt a multi-cloud strategy, where applications primarily run on one cloud but are fully deployable on an alternate cloud to ensure resilience. While not always cost-effective, this approach is essential for mission-critical applications that demand near-zero downtime.

In such cases, the architecture should be designed for seamless deployment across multiple cloud environments with minimal effort, ensuring both flexibility and reliability.

Let's start by assessing the existing infrastructure. The key details below are essential for designing the target solution.

Analysing the Existing infrastructure:

Below is for reference only, while there are many types of applications may exist

  • Application

    • COTS (Commercial Off-the Shelf)

    • Custom

      • Java

      • .net

    • SaaS

    • Containerised

    • Virtual Machines

  • Database

    • Oracle

    • SQL

    • Postgress

  • Middleware

    • Kafka

  • Other Integration components

  • Networks

  • Monitoring and Alerting Solutions

  • Build and Deployment

    • DevOps Methodology

  • Testing

    • Functional

    • Non Functional

  • IT Risk Management process

  • Risk and Governance

  • APRA Compliance (for AU)

Solution Architecture:

The Solution Architecture should include key details, often referred to as the "SoaP" (Solution on a Page) document, which provides a comprehensive overview of a given application. This approach eliminates the need to navigate through multiple documents, consolidating all essential information in one place.

  • Current State

    • Application Status

    • Hosting platform

    • Capacity/Metrics

    • Architecture

    • Technology Stack

    • Dependency Map (Front and back end), This is very important especially when an application is complex

    • Databases

    • Network Configurations

    • End to End Application Flow

    • Security requirements

    • Certificate Requirements

    • Compliance requirements

    • Testing Requirements

    • Performance Requirements

  • Target State

    • Application Architecture and Design

    • Refactoring (CAST Analysis etc..)

    • Hosting Details

    • Backup and Restore

    • Security Architecture and Design

    • Migration Plan

    • Performance Testing Benchmarks

    • Detailed plan including all other process requirements listed in the current section above.

  • Build and Deployment Process

    • Modernise the application (refactor)

    • Vulnerability scanning

  • Monitoring Solutions

  • Alerting Configurations

Design Review and Sign off:

Ensure Design is up to standards of the Organisational requirements.The network requirements would be the key as its often the on premise and Cloud connectivity establishment for the first time in an hybrid environment

Implementation Phase 1:

DevOps Build and Deploy in non prod environments

Create pipelines to deploy the infrastructure based on the design requirements

Create Pipelines to build the application including all the scanning tools integrated and deploy .

Functionally test the application ensuring its works and accessible by all upstream and downstream components

Perform Non functional and Business Valuation Testing as well.

Implementation Phase 2:

Once the application is thoroughly tested in non prod environment, The production deployment should be performed

Production Readiness:

Every organization will have its own unique checklist of requirements for any application to be hosted in the production environment. Be prepared to ensure all requirements are met, including regulatory standards.

Below are some generic management processes that help control and safeguard the organization. While this is not an exhaustive list, these factors should be considered when designing and implementing solutions:

  • IT Risk Management Process

  • Application Criticality

  • Availability Requirements

  • Confidentiality Requirements

  • Security of the new application and platform design (Secure by Design)

  • Security of the new hosting platform foundations

  • User account management (new or existing)

  • Security of monitoring systems

  • Management of application and platform vulnerabilities

  • Designing and implementing resiliency

  • Managing cyber resiliency

  • Managing disaster recovery (DR) scenarios

    • Active-Active

    • Active-Passive

Happy migrating! Feel free to reach out via email if you have any specific questions or topics of interest. Please note, this is a high-level overview, and the approach to each item may vary depending on the specific architecture and organizational strategy.