Welcome to the first blog post in the overview series dedicated to our 12-step Migration and Modernization Methodology that was adopted by AWS.
In any migration or modernization project, it’s crucial to start with a clear understanding of the system’s components and their relationships. This is where workload definition comes into play. Defining workloads correctly sets the stage for the entire project, making it possible to scope, assess, and plan each step with precision.
Workload definition is one of the most essential phases within the first step of the methodology — Future State Architecture Design. This foundational activity enables us to comprehensively map out the system’s current state, identify key components, and design a robust future state architecture that aligns with the client’s business goals.
In this blog post, we delve into the importance of workload definition and how it serves as the basis for all subsequent migration activities. We’ll discuss the key aspects of workload specification, provide practical examples, and explain why this step is critical for successful migrations. For a more visual overview, watch the first video in our four-part video series, which demonstrates these concepts.
What is a workload?
In a migration project, a workload refers to a collection of related system components — such as databases, applications, scripts, jobs, and ETL processes — that are treated as a distinct, self-contained unit ready for migration. A properly defined workload includes all interconnected elements that could be impacted by migration or modernization due to their dependencies, ensuring that the entire unit operates correctly in the new environment.
Key components of a well-defined workload include:
- Database schema and code objects
- Code for applications, ETL processes, and scripts
- Connections to external systems
- Clearly described dependencies between components
- And more …
Defining workloads helps create a detailed map of the entire system, identifying which components will be moved, modified, or redeveloped. This ensures that every relevant component is accounted for, minimizing the risk of disruption or unexpected issues during migration.
Why is workload definition essential?
Workload definition plays a crucial role in every migration project for several reasons:
- Scoping and categorizing components: By identifying all relevant components, including databases, applications, and scripts, we can categorize workloads and establish a clear project scope.
- Identifying dependencies: A detailed workload specification reveals the dependencies between components, such as an application relying on a specific database schema or a script that automates data transfers between environments. This helps plan the migration or modernization work without breaking functionality.
- Complexity assessment: Each workload has its own level of complexity, depending on factors like the number of components, interdependencies, and required transformations. Defining workloads allows us to assess the complexity of the migration, guiding resource allocation and effort estimation.
- Isolated testing and validation: Defining workloads enables isolated testing and validation of each unit before deployment. This modular approach mitigates risks, as individual workloads can be tested and adjusted independently, ensuring smooth integration into the new environment.
Real-world scenarios for workload definition
Let’s look at how workload definition can guide the migration strategy in different real-world scenarios. If you prefer an animated visual representation of the examples listed below, click on this link to the previously mentioned Workload Definition video, which will take you directly to the chapter with these examples.
Let’s consider a manufacturing system that has evolved over the past two decades. Initially, it relied on an Oracle database and a C++ application for all operations. As the company grew, a Java-based CRM application was introduced, followed by the integration of Salesforce to enhance customer engagement. As database activity increased, SQL scripts were implemented for monitoring, and Oracle Recovery Manager was adopted for backups. With a growing workforce, the company took advantage of SQL Server’s capabilities and launched an HR Data Store and HR Manager app using Microsoft’s technology stack. Their Microsoft license also included SQL Server Integration Services (SSIS), an ETL tool that streamlined data from the HR and CoreData databases to the Oracle Warehouse. An analytical Java application generates insights, while Oracle Business Intelligence provides visual reports.
Workload example #1: SQL Server to Amazon RDS PostgreSQL migration
Suppose a client wants to migrate their HR Department’s SQL Server database to an open-source solution on the AWS cloud. The workload in this scenario includes the SQL Server database, the ETL processes associated with it, and the HRManager C# application that interacts with the database.
Workload example #2: Oracle database PoC migration to Amazon Aurora PostgreSQL
The client wants to evaluate replacing their CoreData Oracle database with an open-source option on AWS. To validate this, they requested a Proof of Concept (PoC) that includes only the CoreData Oracle database, its maintenance components, the Manufacture C++ Application, and the CRM ClientBridge Java application. This isolated workload helps assess the feasibility and performance of the solution without involving unrelated components. Dependencies with external systems, such as HRManager or DataIntegrator ETL, are excluded to keep the focus on validating these four key components.
Workload example #3: Full migration from Oracle to Amazon Aurora PostgreSQL
Following the successful PoC, the client has decided to migrate the CoreData Oracle database to Amazon Aurora PostgreSQL. The workload now includes all components that interact with the Oracle database, such as the Manufacture C++ Application, CRM ClientBridge Java application, and the DealBoost SalesForce Application. The HRManager C# application will remain on-premises, and the DataIntegrator ETL will continue using SQL Server Integration Services, as these components are not directly affected by the database migration.
The last two scenarios focus on the analytics infrastructure.
Workload example #4: Partial migration of Oracle DW to AWS
The client wants to migrate a subset of their Oracle Data Warehouse to AWS (e.g., Redshift or Data Lake) while retaining the main warehouse on-premises. The workload includes the designated data subset and its dependencies to ensure smooth integration with ongoing Oracle operations. We need to adjust the ETL SSIS process to support this partial migration and evaluate the impact on the InsightAnalyzer Java application and Visual Reports, which will continue running on Oracle BI.
Workload example #5: Full migration of Oracle DW to AWS
In the final scenario, the client plans a full migration of their Oracle Data Warehouse to AWS platforms like Redshift or Data Lake. The workload now includes the entire warehouse and all dependent components, such as the InsightAnalyzer Java application, DataIntegrator ETL SSIS, and Visual Reports, to ensure a comprehensive migration strategy and seamless transition to AWS services.
Laying the foundation for a successful migration
Workload definition is a critical first step in any migration or modernization project. By scoping and categorizing system components, understanding their dependencies, and assessing the complexity of each workload, we establish a clear roadmap for the entire project. This structured approach ensures that each migration step is thoroughly planned, minimizing risks and setting the project up for success.
In the next blog post, we’ll explore how to define the future state architecture of a system and outline the key transformations needed to transition seamlessly from the current state to the future state architecture. Stay tuned to learn how we build the strategic roadmap for a successful migration!
