How to move your old server to AWS? A summary of system migration methods, tools, and costs

An increasing number of companies are considering "migrating their systems to Amazon Web Services (AWS)" in order to update their aging on-premises servers and reduce operational costs.

However, when you actually start considering it, many questions arise: which migration method to choose, which tools to use to proceed safely, and how much it will cost.

This article provides a practical overview of the steps and configurations required to migrate on-premises or old physical servers to AWS. It provides an easy-to-understand explanation for those considering AWS migration for the first time, covering typical migration methods (lift-and-shift/replatforming), key tools (AWS MGN, DMS, etc.), costs, and points to note.

What is system migration to AWS?

Migrating your on-premises servers to AWS is more than just relocating your infrastructure; it's more like a replacement, including a review of your operational system and cost structure. Here we'll outline the purpose of the migration and the basic concepts you should keep in mind when considering it.

Purpose of migrating on-premise servers to the cloud

The purpose of migrating systems to AWS is to replace aging hardware, reduce maintenance work, and improve fault tolerance. While maintaining redundant configurations and backup environments is time-consuming with on-premises systems, AWS's managed services make it easy to reduce the burden of updates, which is an attractive feature.

Disaster recovery mechanisms are also standardized, which leads to increased availability. Rather than continuing with an operational platform that has room for improvement, replacing it with a design that requires less initial investment is a more advantageous choice in the long term.

Basic concepts to keep in mind when migrating

When migrating to AWS, you need to decide which cloud service layer (IaaS, PaaS, SaaS) to adopt and how much redesign to do. If you transfer your existing environment as is, it is called lift-and-shift, and if you replace it with AWS's managed services, it is called replatforming.

Either method will affect operational costs and maintenance scope after migration, so choose the method that best suits your goals. Solidifying a plan that takes configuration optimization into account at an early stage will also stabilize the quality of subsequent processes.

Main benefits of migrating your system to AWS

The value of migrating to AWS comes from multiple aspects, including not only reducing the burden of server updates, but also flexible scalability and enhanced security. Here we will summarize the main benefits you will gain after migrating.

Freedom from hardware updates and maintenance

In an on-premises environment, you need to prepare for server failures and part replacements, and maintenance plans and renewal costs are incurred as a fixed cost. With AWS, you can operate without worrying about hardware management, reducing the "human and financial burden" of maintaining equipment.

There is no longer any need to continue to own servers as assets, and you can switch to flexible system operation that is not bound by update cycles.

Flexible scalability and availability

Another advantage of AWS is that it's easy to adjust resource capacity to meet fluctuations in demand. Auto Scaling makes it easy to keep up with sudden increases in processing, and redundancy can be achieved without complex configuration work. Furthermore, a layout spanning multiple availability zones reduces the risk of business interruption in the event of a failure.

Strengthening security, backup and disaster recovery

AWS comes standard with security infrastructure such as encryption, authentication, and audit logs, making it easier to build a comprehensive system than on-premises. Backups using S3 and EBS snapshots are also easy to set up, making it easier to incorporate into disaster recovery scenarios. The ability to strengthen preparations while reducing operational burden is a major reason for considering migration.

Visualization and optimization of operational costs

AWS's pay-per-use pricing makes your spending structure transparent, helping you avoid excessive capital investment. It also offers pricing optimization mechanisms such as Reserved Instances and Savings Plans, making it easier to design costs based on operational performance. Continuous usage visualization also makes it easier to identify areas for improvement.

Basic steps for migrating your AWS system

Migrating to AWS is likely to result in a lot of rework if you proceed haphazardly, so we will proceed by organizing the steps in stages. Here we will explain the general steps in practice.

STEP 1. Inventory the current environment and organize the scope of migration

The first task is to accurately understand the current system. By identifying the server configuration, applications in use, databases, network connections, dependencies, etc., you can determine how much of it needs to be migrated to AWS. Proceeding without clear configuration information can lead to unexpected service outages later on, so it's important to avoid any omissions during the inventory stage.

STEP 2. Select a migration method (re-host/re-platform/re-architect)

The migration method depends on the extent to which the configuration needs to be changed to suit AWS. Typical methods include lift-and-shift, which involves moving the system while preserving the existing configuration, replatforming, which involves partially replacing it with a managed service, and rearchitecting, which involves redesigning the entire architecture. The appropriate method is selected based on the system scale, capacity, and future scalability.

STEP 3. Designing the AWS environment (VPC, IAM, monitoring, backup)

Once the migration method has been decided, the basic configuration on the AWS side can be designed. It is necessary to solidify in advance the VPC configuration that will serve as the network boundary, the IAM that will manage authentication and authorization control, the monitoring settings that will support operations, the backup policy, and so on. The precision of the design here is directly linked to the stability and security quality after migration.

STEP 4. Execute data/application migration

Once the design is complete, you can actually move your data and applications to AWS. The standard approach is to select a migration tool based on the intended use, such as DataSync for file storage, AWS MGN for servers, and DMS for databases. By utilizing gradual replication, you can prepare for the switchover while minimizing the impact on business operations.

STEP 5. Test and switch to production

Rather than immediately going live after migration, we conduct pre-tests to check the configuration and performance. When switching to live, we will implement the switchover procedure and rollback path only after establishing it. Multifaceted checks, including the timing of DNS switching and enabling monitoring settings, will lead to stable operation.

STEP 6. Post-migration optimization and operational design

Even after the start of production operations, there is a process of reviewing the configuration based on monitoring results and load trends. Instance types and scale designs are adjusted, and pricing optimizations such as Savings Plans are also implemented. Establishing operational rules and response procedures will help ensure the effects of the migration are firmly established.

Official AWS tools and services for migration

AWS offers several official tools for various migration purposes. Here we will introduce four commonly used services according to their purpose.

AWS Application Migration Service (MGN)

AWS Application Migration Service (MGN) is ideal for migrating physical and virtual servers running on-premises to AWS.

Because the system replicates existing OS and applications without changing them, downtime can be minimized even during production operations. It is easy to configure the system to switch over after migration and verification, making this a service that is often adopted in the initial phase.

AWS Database Migration Service (DMS)

AWS Database Migration Service (DMS) is used for online database migrations.

It supports continuous replication, which allows migration without interrupting business operations, and can correct for differences in the structure between the source and destination. It is often used when migrating from Oracle, SQL Server, or MySQL to Aurora, etc., and is used as a method to shorten downtime when switching databases.

AWS DataSync

AWS DataSync is a service suitable for transferring large files and storage. It allows you to transfer data directly from your on-premises NAS or file server to S3 or EFS, and automatically handles encryption and compression.

Its bandwidth control function allows continuous transfer without affecting business traffic, making it suitable for gradual migration and overnight batch migration scenarios.

AWS Migration Hub

AWS Migration Hub is a unified management service that provides visibility into your entire migration project.

Even when using multiple tools such as MGN and DMS, you can grasp the progress status from a central location. This is particularly effective for migration projects with many staff members or long-term projects, and allows for operational management that separates planning and implementation.

Migration pattern examples for different system configurations

The optimal migration method and configuration will vary depending on the system scale and requirements. Here we will introduce migration concepts and configuration examples divided into four major categories.

Small-scale systems (file servers, internal applications)

Small-scale systems can be migrated to the cloud relatively smoothly because they have few components and dependencies are easy to organize. For file servers, choosing S3 or FSx as the migration destination and integrating permission management with IAM can reduce operational burden. In-house web applications often work simply by moving them to EC2, but there is also room for development into ECS and serverless in the future.

Business systems (accounting, sales management, etc.)

Business systems such as sales management and accounting require a gradual migration that takes into account maintenance contracts and license structures. The typical approach is to first ensure stable operation using a lift-and-shift system while maintaining the existing configuration, and then replace some components with managed services. Standardizing audit logs and backups at the same time will also help establish operations after the migration.

Mission-critical systems and databases (Oracle, SQL Server, etc.)

For mission-critical systems, reducing downtime and maintaining availability are priorities when migrating. When migrating to a cloud-native database such as RDS or Aurora, gradual migration using DMS is effective and is suitable for a configuration that continues synchronization while maintaining production operations. When dealing with large-capacity databases, the shortcut to success is to conduct repeated pre-verification, including storage I/O and region configuration.

Web applications/external disclosure systems

Web applications are an area where AWS's strengths are easily reflected. First, by incorporating a load balancer and auto scaling, it becomes easier to prevent performance degradation during sudden increases in access. Combining WAF and CloudFront also enables both security and delivery optimization. If you are looking ahead to future expansion, consider designing your system to be containerized or serverless.

Estimated cost of AWS migration

When migrating to AWS, it's important to understand the overall picture, including not only the initial costs but also the monthly and operational costs after the migration. Here we'll break down the costs and outline the points to consider when making an estimate.

Initial costs (design, PoC, data migration)

Initial costs include "current situation confirmation and environment design," "PoC (verification)," and "testing costs before the actual relocation." Particularly if the existing system is complex or dependencies are difficult to understand, a certain amount of work will be required during the inventory stage. The work of downloading data from physical servers will primarily involve the installation of AWS MGN, and the relocation time and costs will vary depending on the amount of data.

AWS usage fees (EC2, S3, RDS, etc.)

Running costs incurred after operation are primarily determined by three elements: computing, storage, and network. For example, with EC2, costs are directly related to the instance type and operating time, while with S3, costs are directly related to the amount of data stored and the number of requests. RDS also charges differently depending on the storage type and redundancy configuration, so resource allocation based on load characteristics is required.

Operation and monitoring costs

While AWS operations offer more flexibility than on-premises systems, proper monitoring and security configurations are essential. Unifying cloud monitoring with CloudWatch and including automatic notifications in the event of an outage can reduce the workload of your internal CS team. However, because maintenance and security improvements require expertise, some companies may also include support costs from external partners as needed.

Cost optimization points (RI/SP/auto-scale)

With AWS, it's common to monitor the situation with on-demand billing immediately after relocation, and then switch to reservation-based billing (RI/SP) once operation has stabilized. Automatically adjusting resources with the scaling function allows for efficient operation in line with actual usage. Once the basis for billing calculations is in place, visualizing the overall picture with Cost Explorer makes it easier to identify potential savings.

Common migration challenges and failure patterns

When migrating to AWS, even if the design and procedures themselves are correct, if you proceed without sufficient preparation and understanding of dependencies, unexpected problems can occur after the start of operations. This article explains common patterns that occur in practice and the background to them.

Downtime due to lack of understanding of dependencies

In a business environment where multiple systems are connected, proceeding with the relocation without identifying the dependencies between applications and batch processes can lead to communication disruptions and data sharing suspensions after the switchover. Particular care is required in designs that involve file sharing or external APIs. It is safer to inventory the connection destinations and sources at an early stage and determine whether or not to relocate in stages.

Licensing issues (Windows/Commercial DB)

The licensing system for operating systems and middleware may change with the move to the cloud. The cost of Windows Server, Oracle Database, and other software varies depending on whether you use a BYOL license or an AWS-provided license, and making the wrong choice can lead to higher charges. It's essential to determine your usage method and provider in advance and confirm whether they're cloud-compatible.

Network settings/security errors

Many of the problems that tend to occur in a post-migration environment are network-related. Misunderstanding communication requirements and CIDR design can lead to poor connections and VPN bandwidth depletion. It's safest to also check security group and NACL settings, and verify behavior through a migration test before switching to production.

Operation and monitoring design postponed

In some cases, the priority is given to completing the migration, and post-going monitoring and operational maintenance are put off. After switching to production, establishing an operational plan including CloudWatch and AWS Backup will lead to stable cloud operations. The ideal configuration is to create a relocation plan in parallel with operational maintenance.

My Feelings, Then and Now

Migrating to AWS is not just about updating aging on-premises servers; it's also an opportunity to overhaul your operational design and cost management. To ensure a smooth migration, it's best to carefully take stock of your current situation and gradually verify your migration method against the AWS configuration. Continuing to monitor and optimize your system even after the migration will provide long-term benefits in terms of scalability and availability.