From on-premise to cloud | AWS migration procedures, tools, and configuration concepts

Migrating from an on-premises environment to AWS is a major challenge facing many companies. However, many are unsure of where to start and how to proceed without failure. This article explains the basic steps for migrating to AWS, how to think about configuration design, and how to choose the most popular migration tools, all in a way that makes it easy to implement even for first-time migrations.

What is on-premise to AWS migration?

Migrating from an on-premises environment to AWS is an important issue facing many companies. By migrating systems from a traditional on-premises environment where servers, storage, and network equipment are owned and operated in-house to a cloud platform provided by AWS, many benefits can be obtained, including cost optimization, improved availability, and operational efficiency.

However, the migration method and scope of redesign will vary greatly depending on the configuration of the current system and business requirements. This section explains typical migration patterns, their characteristics, and the benefits obtained from migration.

Typical patterns of on-premise migration

There are three main patterns for migrating to AWS. It is important to choose the method that best suits your company, taking into consideration the migration period, cost, and benefits of moving to the cloud.

Re-host (lift and shift)

This is a method of migrating existing servers and applications almost as they are to EC2 on AWS, etc. Configuration changes are kept to a minimum, allowing for cloud migration in a short period of time.

• Benefit

  • Rapid migration is possible, allowing you to start using the cloud in a short period of time

  • No app modifications are required, making it easy to keep initial costs down (minor modifications may be required).

• Demerit

  • Operational load and cost structure are not significantly different from the on-premise era

  • There is a risk of bringing in technical debt

• Suitable cases

  • Hardware maintenance is expiring and migration is urgently needed

  • The verification period is limited

  • We want to start with AWS and then gradually modernize.

Re-platform

This is a migration method in which the application itself is not significantly changed, but the peripheral infrastructure is replaced with AWS managed services. For example, moving the database to RDS, the file server to Amazon FSx or S3, etc.

• Benefit

  • Significantly reduces operational burden

  • Availability and scalability are improved, allowing you to enjoy some of the benefits of the cloud

• Demerit

  • A certain amount of work is required for verification and adjustment

  • Without careful migration planning, there is a high risk of service outages during the migration.

• Suitable cases

  • There are issues with operation and maintenance, and it is urgent to improve efficiency through management

  • Cost optimization is a mid-term goal

  • We want to proceed with gradual modernization with a view to re-architecting in the future.

Re-architect (re-architect/modernize)

It is an approach to redesigning applications to be cloud-native, involving a move to microservices and serverless architectures.

• Benefit

  • Greatly improves scalability and development speed

  • Maximize automation and efficiency of operations

  • Directly linked to cost optimization and business value creation

• Demerit

  • Design and development costs are high, and projects tend to be long-term

  • Advanced AWS skills and structure required

• Suitable cases

  • The existing system has a large amount of technical debt and needs to be rebuilt

  • The service needs to grow rapidly

  • We are promoting organizational transformation based on a DevOps culture.

Benefits and main effects of on-premise migration

Migrating to AWS is not just about moving servers, it brings a lot of added value to companies. The main benefits are as follows:

Cost reduction

• Convert fixed costs (CapEx) such as hardware purchases and data center maintenance costs into variable costs (OpEx)

• Resources can be increased or decreased flexibly depending on usage.

• Easily optimize costs with reserved instances and savings plans

Flexible scalability

• Instant scaling out/in to accommodate sudden increases in traffic or business expansion

• Smooth global expansion by utilizing overseas regions

Improved availability and disaster prevention

• Standardizing multi-AZ configuration minimizes the impact of system failures

• Backup and DR (disaster recovery) environments can be built at low cost and in a short period of time.

Reduced operational burden

• By utilizing managed services such as RDS, ECS, and Lambda, operational tasks such as patch application and troubleshooting can be reduced.

• Monitoring and automation using CloudWatch and EventBridge allows for operation by a small number of people.

Basic steps for AWS migration

When migrating from an on-premises environment to AWS, the process is roughly as follows: Preparation → Design → Execution → Optimization. By clarifying the tasks required at each step, you can proceed with the migration in a planned manner.

1. Migration Preparation

A successful AWS migration depends on preparation at the initial stage. It is important to correctly understand the current situation and clarify what needs to be migrated and what priorities to set.

Inventory and classification of migration targets

• List existing systems, servers, applications, databases, storage, etc.

• Organize frequency of use, importance, and dependencies

• Classify future directions such as "migrate," "abolish," and "go cloud-native"

Prioritization and scoping

• Determine priorities based on importance, risk, and difficulty of migration

• Select a system suitable for verification and PoC (proof of concept)

• Clarify the initial scope of the transition and develop a phased plan

TCO analysis and migration effect evaluation

• Visualize the costs of on-premise environments (hardware maintenance costs, electricity, operational labor costs, etc.)

• Estimate running costs after migrating to AWS

• Compare return on investment (ROI) and total cost of ownership (TCO) and prepare executive presentations

2. Design and Planning

Based on the information obtained during the preparation stage, we design the configuration on AWS and finalize the migration plan.

Landing Zone Design

• Designing governance management with Organizations based on a multi-account strategy

• Define account separation, OU (organizational unit) design, and baseline policies

• Planning includes security infrastructure and audit log aggregation design

Network/Security/Monitoring Design

• VPC design, Direct Connect and VPN connection method decisions

• Encryption design using IAM policies and KMS

• Establishment of an operational monitoring system using CloudWatch and CloudTrail

Building a test environment

• Build and test PoC and staging environments before moving to production

• Check expected problems and performance

• The operation of migration tools and scripts is also checked at this stage.

3. Execute the migration

Based on the details finalized during the design phase, we will actually migrate your data and systems to AWS.

data migration

• Mass data transfer using AWS DataSync and Snowball

• The database was migrated in stages using AWS Database Migration Service (DMS).

• Establish a system to check data integrity during migration

Server/Application Migration

• Lift and shift VMs to AWS with AWS Application Migration Service (MGN)

• Some replatforming is achieved through containerization and serverless

• After migration, redundancy is ensured using Elastic Load Balancing etc.

Validation and production cutover

• Post-migration operation check (performance/functionality testing, user acceptance testing)

• Use staged releases (Blue/Green, Canary releases) when switching to production

Optimization and Tuning

• Optimize resources and costs based on post-operation monitoring results

• Reduce operational costs by introducing Auto Scaling and Reserved Instances

• Continually improve operational design and establish a cloud operations culture

Migration issues specific to on-premise systems and points to consider

When migrating from an on-premises environment to AWS, not only do you encounter challenges specific to cloud migration, but you also encounter many constraints and problems unique to on-premises environments. This chapter explains common problems you may encounter in migration projects and how to address them from a practical perspective.

Common organizational challenges in on-premise migration

H4: The division of responsibilities between departments tends to be unclear.

Cloud migration involves multiple departments, including IT, development, operations, and security. If authority and responsibility remain unclear, configuration errors and delays in decision-making are likely to occur.

Countermeasure examples:

• Creating a role assignment table using a RACI chart

• Agree on the design and approval process in advance

Clarifying the roles of the existing operations team and the cloud team

Because on-premise and AWS operating styles differ, overlapping roles and conflicts tend to occur within the operations team.

Countermeasure examples:

• Redefining the scope of responsibility for AWS operations

• Planned integration of monitoring and operational tools

Tips for identifying dependencies on on-premise assets

How to handle HW-dependent applications

Applications that are highly dependent on hardware, such as specific NICs or USB keys, cannot be migrated to AWS as is.

Countermeasure examples:

• Consider alternatives (virtual devices, changing licensing methods)

• If it is difficult to reproduce using Lift & Shift, consider replatforming.

Support for legacy OS/old licensed products

Operating systems not recommended by AWS, such as Windows Server 2008 or older UNIX operating systems, must be upgraded before migration.

Countermeasure examples:

• Implement OS update planning in the pre-migration phase

• Check vendor support availability

Organizing connection requirements with on-premise network environments

Direct Connect/VPN selection and configuration example

During migration, it is necessary to securely connect AWS and on-premises.

• VPN connection: Can be set up in a short time, but bandwidth is limited

• Direct Connect: Suitable for large-volume data transfers and production connections

Consistency with existing on-premise network policies

If the security groups and ACLs on the AWS side do not match the on-premises firewall settings, communication problems will occur after migration.

Countermeasure examples:

• List IP ranges and port requirements in advance

• Reviewed by both network design teams

On-premise storage migration patterns and points to note

H4 NAS/SAN Migration Considerations

• SMB and NFS access permissions must be maintained during migration.

• Consider replacing with AWS services such as FSx for Windows/NFS

Practical Tips for Migrating Large Files (Using DataSync/Snowball)

• Transfer tens of TB of data online with AWS DataSync

• For volumes in the hundreds of TB range, physical transportation using AWS Snowball is efficient.

Common issues with lift and shift of physical servers/VMs

How to deal with driver/agent compatibility issues

• Cases where incompatibility occurs with virtualization software or AWS drivers

• If you are using AWS MGN, update to the latest version before migrating.

Refactoring MAC address dependent apps

• Be careful with license management systems that operate on the premise of a fixed MAC address

• License reconfiguration required when creating an AMI or building a new system

Key points for redesigning on-premise licenses

Software license cloud compatibility confirmation flow

• Check whether the software you plan to migrate has an AWS-compatible license.

• Negotiate with vendors early if license model changes are necessary

Points to note when using BYOL (Bring Your Own License)

• EC2-specific license requirements and support conditions must be met

• License trail management for audit compliance

On-premise job management/batch migration organization

AWS migration options for on-premise cron/job schedulers

• Scheduled execution in EventBridge

• Workflow management with Step Functions

• AWS Batch and third-party job management tools are also available as options

Example of test pattern during migration

• Checking schedule operation after migration

• Checking parallel execution and retry processing

• Verification of monitoring and notification integration

Practical tips for migrating on-premise databases

Problems that tend to occur when migrating from a commercial database to Aurora

• Data type and stored procedure compatibility issues

• Forgot to change the connection string of the external connection app

Phased migration pattern for large-scale databases

• Pilot migration: Preliminary test on a small database

• Phased switchover: Synchronize data during production and minimize downtime with a final switchover

How to ensure consistency with on-premise operational monitoring

Keep your existing monitoring system or integrate with AWS services? Decision criteria

• Maintain existing monitoring in the short term, but migrate to CloudWatch and Managed Grafana in the long term

• Decide based on the skills and costs of the operations team

Example of monitoring architecture in a hybrid cloud configuration

• Integrated management of metrics for both on-premise and AWS

• Logs are centrally aggregated in CloudWatch Logs

Creating organizational culture and operational structure when migrating from on-premise to AWS

Typical examples of failure when changing the organization for cloud operations

• Ad hoc authorization leads to security incidents

• Operational flow remains rigid as it was in the on-premise era

How to shift skills and train existing staff

• Systematic training utilizing AWS certifications and hands-on training

• Establishing a "Cloud Operations Team" from the beginning of the migration to share knowledge

Considerations for configuration design when migrating to AWS

When migrating from an on-premises environment to AWS, you don't just move servers and data to the cloud; you also need to optimize network, security, and availability designs for the cloud. This chapter explains how to design a configuration that will ensure stable operation after migrating to AWS.

Network design points

When migrating to the cloud, it is important to maintain connectivity with on-premises networks while achieving flexible communication design on AWS.

On-premise connection (Direct Connect/VPN)

• VPN connection

  • Can be constructed in a short period of time. Initial costs can be reduced.

  • Bandwidth is limited, making it suitable for testing and small-scale migrations

• AWS DirectConnect

  • High-bandwidth, stable connection via dedicated lines

  • Essential for large-scale migrations and production operations

VPC design

• Carefully design the VPC that will serve as the network infrastructure on AWS before migrating

• Key Points

  • Divide VPCs by account or system

  • Design public/private subnets appropriately according to security requirements

  • Include network expansion plans using VPC Peering and Transit Gateway

Segment Design and Routing

• Optimize network segments for AWS without migrating them as they were in the on-premise era

• Clarify the CIDR plan for each subnet

• Organize the relationship between security groups, NACLs, and route tables to implement multi-layered communication control

Key points in security design

After migrating to the cloud, the concept of security management differs from that of on-premises systems. It is important to utilize the functions provided by AWS and automate controls.

IAM and Access Control

• Leverage IAM user, role, and policy to operate with least privilege

• Establishment of an integrated authentication infrastructure using SSO (AWS IAM Identity Center)

• Design authorization rules in advance and define operational flows

Encryption and Log Management

• Storage such as S3 and EBS is encrypted by default

• Audit log management using CloudTrail and CloudWatch Logs

• Unified key management with KMS (Key Management Service)

Governance and Compliance

• Leverage AWS Organizations to centralize account control

• Restricting services using SCP (Service Control Policy)

• Pre-designed configurations to meet industry regulations (PCI DSS, HIPAA, etc.)

Availability and Backup Design

After migrating to the cloud, we will incorporate plans for switching and recovery in the event of a failure, assuming that the system will not stop.

Multi-AZ/Multi-Region Design

• Multi-AZ configuration

  • Production systems must be distributed across multiple AZs

  • The database uses Aurora or RDS multi-AZ configuration as standard.

• Multi-region configuration

  • Consider replicating to another region as a DR measure

  • Design a failover configuration using Route 53

Backup/restore basic policy

• Backup target: DB, S3, EBS, configuration information (including IaC)

• Key Points

  • Backup policies are automated (using AWS Backup)

  • Conduct regular restore tests to verify recovery time (RTO) and data loss tolerance (RPO)

  • Designing a storage period and management system that complies with laws and regulations

Key tools for AWS migration

Choosing the right tools is essential for a smooth and safe migration to AWS. Here we will introduce some official AWS tools and some representative third-party tools.

AWS-provided tools

The tools provided by AWS are designed with cloud migration in mind, giving you peace of mind in terms of support and service integration.

AWS Application Migration Service (MGN)

A migration tool for lifting and shifting on-premises physical servers and virtual machines (VMware, Hyper-V, etc.) to AWS.

• Features

  • Real-time replication without impacting production

  • Migration possible with minimal downtime

  • After migration, you can switch to production after verification on AWS.

• Use

  • Ideal for those who want to migrate existing servers to the cloud as is

AWS Database Migration Service (DMS)

A service for migrating on-premises or other cloud databases to RDS or Aurora on AWS.

• Features

  • Supports gradual migration from a running database (minimizing downtime)

  • Supports migration not only between homogeneous databases but also between heterogeneous databases (e.g., Oracle → Aurora)

• Use

  • Suitable for mission-critical database migrations where business cannot be stopped

AWS DataSync

A tool that automates large-volume data transfers between on-premises and AWS, or between AWS services.

• Features

  • Supports SMB/NFS and is strong in migrating between storage devices

  • Data compression and encryption ensure safe and efficient transfer

• Use

  • Migrating NAS and file servers, transferring large amounts of data to S3 and EFS

AWS Migration Hub

A centralized dashboard for managing multiple migration projects.

• Features

  • Visualize the progress of multiple tools such as MGN and DMS

  • Track migration progress by project

• Use

  • Useful for managing multiple teams on large-scale migration projects

Third-party tool examples

Areas that cannot be addressed using official AWS tools alone can be resolved by combining them with third-party tools.

Data backup/migration tools

• Veeam Backup & Replication

  • Supports data protection for on-premise and multi-cloud environments, including AWS

VM migration support tool

• CloudEndure Migration (Legacy Product)

  • It is now integrated into AWS MGN (Application Migration Service), and there is virtually no use of CloudEndure Migration.

Monitoring/automation support tools

• New Relic

  • You can centrally manage the monitoring of the entire system, including AWS and on-premise systems.

  • Supports application performance visualization and alert management

• Terraform / Ansible

  • Effective for configuration management and migration automation using IaC (Infrastructure as Code)

Common migration challenges and how to avoid failures

AWS migration projects often fall into unexpected pitfalls even when they are proceeding according to plan. Here we will explain common failure patterns and how to prevent them.

Lack of preparation leads to schedule delays

In AWS migration projects, insufficient initial preparation can cause schedule delays, increased costs, and friction with related departments. In particular, if an inventory of the current system and a clear definition of the migration scope are not made, problems such as "unintentional servers being discovered" and "data dependencies not being confirmed" frequently occur in later processes.

• Assignment example

  • Inventory of the current system was insufficient, and servers and applications that were not included in the migration were discovered later.

  • Plans change frequently due to unclear scope and lack of prioritization

  • Problems occurred during the actual migration due to insufficient prior verification of migration tools and procedures.

• Prevention measures

  • Gain complete visibility into application dependencies early on

  • Conduct a proof of concept (PoC) to confirm the applicability of procedures and tools

  • Document the migration target and scope and get everyone involved to agree before starting

Poor operational design after migration led to rework

Even if you migrate your system to AWS, if the post-migration operational design is insufficient, you will have to go back and do things again. If you start operations without clear IAM permission design, monitoring system, backup policy, etc., the risk of security incidents and delays in responding to failures increases. Solidifying the operational design in parallel with the migration work will ensure stable operation after the migration.

• Assignment example

  • The AWS operation system after migration was not in place, and configuration changes were ad hoc

  • Ambiguous authorization design (IAM) increases security risks

  • Lack of integration in operational monitoring leads to delayed fault detection

• Prevention measures

  • Formulate operational design in advance in parallel with migration planning

  • Clarifying IAM rules, monitoring systems, and backup policies

  • Establishing an AWS operations team and starting skills training early

Communication failure due to network design error

AWS migration requires complex network design, including connections between on-premises and AWS, and VPC configuration within AWS. Inappropriate CIDR and routing design can lead to problems such as disconnection of inter-system communications and significant drops in transfer speeds after migration. A thorough review from both on-premises and cloud perspectives is essential.

• Assignment example

  • Inadequate VPC design and CIDR planning leads to subnet conflicts

  • The connection method between on-premise and AWS was inappropriate, resulting in problems with transfer speed and stability.

  • Communication is not possible due to holes in the firewall settings or security group settings

• Prevention measures

  • Network design reviewed by both on-premise and AWS teams

  • Consider a configuration where VPN connection is used initially, and then switching to Direct Connect when moving to production.

  • Document CIDR and route tables and implement change management

Insufficient data integrity check

Even if the migration process is completed smoothly, if data integrity is not guaranteed, it can lead to system failures and business interruptions. Synchronization errors and data loss are particularly likely to occur when migrating large databases or file servers, so it is important to establish a post-migration check system in advance.

• Assignment example

  • After data migration, production operation is started without consistency check.

  • During a large-scale database migration, differential data was not synchronized, causing a system failure.

  • Insufficient encryption and error detection during file transfer

• Prevention measures

  • Be sure to include a migration test phase

  • Use AWS Database Migration Service (DMS) or DataSync to monitor transfer logs

  • Verify data integrity by comparing checksums and record counts

Cases where costs rise more than expected

The appeal of the cloud is its flexible billing model, but if you operate it without reviewing your configuration after migration, costs may increase compared to the on-premises era. It is important to be aware that underutilization of reserved instances and hidden costs such as transfer fees and backup storage are easily overlooked in estimates. The key to success is to monitor costs from the early stages of migration and to optimize them early on.

• Assignment example

  • Even after migration, the same configuration as on-premise is maintained, preventing the use of cloud features.

  • Reserved instances and Savings Plans are not being used, causing on-demand charges to balloon

  • I forgot to include the migration tool usage and data transfer fees in the preliminary estimate.

• Prevention measures

  • Visualize costs immediately after migration with AWS Cost Explorer and Trusted Advisor

  • Early analysis of resource usage patterns and reservation-based billing

  • Conduct a TCO analysis in advance, including data transfer and storage costs