Welcome to the second blog post in the overview series dedicated to our 12-step Migration and Modernization Methodology that was adopted by AWS. In the first blog post, we began exploring the first step of the methodology — Future State Architecture Design.
We focused on the definition of a workload and outlined how categorizing system components into specific workloads provides a solid foundation for the entire project. However, workload definition is just one part of the broader Future State Architecture Design step. In this blog post, we will continue the discussion by detailing how we translate these workloads into both current and future state architectures.
If you prefer to access the same information provided in this blog post in video format, please watch the second video in our four-part video series, which demonstrates these concepts.
Understanding current and future state architecture transformation
Once workloads are defined, the next task is to map these workloads to the current state architecture, then envision and design their future state. This step involves a detailed comparison of how each workload component functions in the existing environment versus how it will be structured in the new one. This process helps identify the transformations required to support the client’s business goals and establish a technical blueprint for migration.
By thoroughly understanding both the current and future architectures, we can ensure that each workload component is efficiently transitioned and optimized, setting the stage for a successful migration project.
Revisiting the five workload scenarios
Let’s revisit the five workload scenarios we introduced in the first blog post and examine how we defined the current and future state architectures for each scenario.
Scenario #1: SQL Server to Amazon RDS PostgreSQL migration
Business goal: The client wants to migrate their HR database from a Microsoft SQL Server to an open-source database on AWS, such as PostgreSQL, while keeping the HRManager C# application on-premises.
Current state: The HR department’s data is stored in an on-premises SQL Server database, and SSIS is used for ETL processes. The HRManager C# application connects to this SQL Server database to perform various business operations.
Future state: The SQL Server database is migrated to Amazon RDS for PostgreSQL, while the ETL functionality is recreated using AWS Glue. The HRManager C# application is updated to connect to the new PostgreSQL database without altering its on-premises deployment.
To ensure a smooth migration, it’s essential to create a detailed transformation table that maps each component of the current architecture to its future state equivalent. This table outlines the transformation type (e.g., schema conversion, ETL migration), the tools used (e.g., AWS SCT, AWS DMS, Azure DMS, SSMA, GC DMS), and the expected level of automation. Such detailed planning allows us to estimate the project phases accurately and prepare a comprehensive project execution plan.
Transformation table for this scenario:
Scenario #2: Oracle database PoC migration to Amazon Aurora PostgreSQL
Business goal: The client wants to test the feasibility of migrating their CoreData Oracle DB to AWS. This Proof of Concept (PoC) includes migrating the Oracle DB, its maintenance tools, and related applications except for the HRManager C# application.
Current state: The CoreData Oracle DB, Manufacture C++ application, and CRM ClientBridge Java app are deployed on-premises. Oracle-specific tools, such as Recovery Manager, handle backups and performance monitoring.
Future state: The CoreData Oracle DB is replaced with Amazon Aurora PostgreSQL. The Manufacture and CRM applications are moved to Amazon AppStream 2.0, a managed application streaming service that allows cloud-based application access. Backup and performance monitoring tools are replaced with Amazon Aurora Backup and Amazon CloudWatch, ensuring better integration and visibility across the AWS Cloud.
Transformation table for this scenario:
The success of this PoC will determine the viability of a full-scale migration strategy.
Scenario #3: Full migration from Oracle to Amazon Aurora PostgreSQL
Business goal: Based on the successful PoC, the client is ready to execute a full migration from Oracle to Amazon Aurora PostgreSQL.
Current state: The CoreData Oracle DB, Manufacture C++ application, and CRM ClientBridge Java app operate on-premises. The HRManager C# application connects to the Oracle database for specific data access.
Future state: The entire CoreData Oracle DB is migrated to Amazon Aurora PostgreSQL. Both Manufacture and CRM applications are moved to Amazon AppStream 2.0, and their connections are updated to interact with the new PostgreSQL database. Additionally, Oracle Recovery Manager is replaced with Amazon Aurora Backup, and database monitoring is handled by both CloudWatch and Amazon Aurora Performance Insights.
Transformation table for this scenario:
Scenario #4: Partial migration of Oracle DW to AWS
Business goal: The client wants to migrate a subset of their Oracle Data Warehouse to AWS platforms like Amazon Redshift while keeping other components on-premises.
Current state: The Oracle Data Warehouse, along with ETL processes, analytical applications, and reporting tools, is fully deployed on-premises.
Future state: A designated subset of the Oracle Data Warehouse is migrated to Amazon Redshift. The on-premises DataIntegrator ETL SSIS, InsightAnalyzer Java app, and Oracle Visual Reports remain unchanged but are adjusted to integrate with the new Redshift subset.
Transformation table for this scenario:
Scenario #5: Full migration of Oracle DW to AWS
Business goal: The client wants to fully migrate their Oracle Data Warehouse and supporting applications to AWS.
Current state: The entire Oracle Data Warehouse is on-premises, along with ETL, analytical, and reporting applications.
Future state: The Oracle Data Warehouse is migrated to Amazon Redshift, and the InsightAnalyzer Java application is moved to Amazon AppStream 2.0. AWS Glue replaces the ETL SSIS, and Oracle Visual Reports are recreated using Amazon QuickSight. This setup allows the client to utilize AWS-native services for enhanced analytics and reporting.
Transformation table for this scenario:
What’s Next?
In the next blog post, we will explore the Analysis phase, where we gather and analyze the project artifacts to validate the proposed transformations and refine the project scope. This step helps us break down each migration phase into actionable tasks, ensuring that every aspect of the project is well-defined before execution begins.
