Cloud lift or modernization: where to start with AWS

The maintenance deadline for your servers is getting close. At the same time, every change to a function in the current system takes a long time to research and test. When you consider moving to AWS, you often have to think about renewing the operating environment and reviewing the application at the same time.

The question to decide then is the scope and order for two approaches: a “cloud lift” that moves the current system to AWS as it is, and a “modernization” that reviews the structure and functions of the system.

The starting points for that decision are the deadlines you must meet, the problems you face in daily work, and what you want to achieve next. While confirming the role the current system plays, we sort out how to proceed with migration and renewal.

How a cloud lift and a modernization differ

A cloud lift moves the operating environment to a cloud such as AWS while keeping changes to the existing application small. In the AWS migration strategies, moving an application basically without changing it is called “rehost.”

Modernization reviews the application, database, infrastructure and so on to fit future business and operations. The targets depend on the purpose, such as making processing easier to change, solving performance problems or reducing the operational workload.

There is also an option called “replatform,” which optimizes part of the infrastructure as you move to AWS. Between migration and renewal, there are several ways to proceed depending on how much you change.

First, decide what needs to be solved first

Sorting out the situation as in the examples below helps show where to start.

When you need to act quickly on a hardware maintenance deadline

If you want to keep using the current business functions, one option is to keep changes to the existing application small and do the cloud lift to AWS first.

Confirm the operating conditions on AWS, the licenses and the connections with surrounding systems, and plan the migration around when the business can switch over.

When even small changes need a lot of research and testing

If changing one function means researching its effect on many other processes, consider modernizing the application.

Sort out the dependencies between processes and data, and confirm which functions change often and which conditions current work requires. Then decide where to start reviewing the structure and functions so that future changes become easier.

When operational work such as backups and incident response is heavy

If daily operations take a lot of time, review the AWS infrastructure design and the way it is operated together.

Sort out how far AWS managed services can be used, which tasks remain after the change, and who is responsible for them. Consider a design that fits the business from both sides: the cost of the services and the time spent on operations.

The AWS migration guidance also describes choosing a migration strategy for each application or component based on business goals and technical conditions.

Note that moving to AWS does not by itself extend the support period of an old operating system or middleware. When dealing with maintenance deadlines, check the conditions for hardware and software separately.

The specifications of an existing system have reasons behind them

Business systems used for many years contain agreements with business partners, responses to past problems and exception handling that the people on site needed.

For example, processing that looks duplicated may calculate differently for certain transactions, or create data in another format to pass to a surrounding system. If the original developers have left and documents are not sufficient, the research starts with confirming those reasons.

In a modernization, it is important to read the current processing and understand which work it supports. Sorting out the conditions still needed, the parts covered by manual operation and the functions that have already finished their role makes it easier to decide what to keep and what to review.

This work also affects renewal estimates and investment decisions. Once you know what the current state survey, data migration, connections and testing require, you can explain why the costs arise and what effects the review should bring.

Make a step by step plan that includes improvement after migration

Another approach is to put the maintenance deadline first, do the cloud lift, and then renew the application in stages.

In that case, the migration plan should clearly state what will be reviewed later and the conditions for starting. For example, set priorities starting from functions that change often, functions with long processing times, and areas where investigating incidents takes time.

In a large modernization, the connections between systems also affect the order. If systems share authentication, databases, file transfers or night batches, changing only some of them first means preparing extra ways to connect them during the migration period. AWS also describes grouping migration targets after understanding dependencies and business cycles.

When comparing costs, include not only the initial build but also running the old and new environments in parallel, data synchronization, and operations and further changes after migration. Understand the extra work that a staged approach adds, and build the plan from both the deadline and the expected improvement.

Confirm that the business can continue before switching over

To judge that a move to AWS or a system renewal is complete, you need to confirm that actual work can be done.

Besides daily operations, the checks cover totals at the end of the month, night processing, connections with external systems and performance at busy times. Also sort out who handles monitoring, backups and inquiries after migration, and how.

For the production switchover, decide in advance how long the business can stop, how to handle data created during the migration, who decides to continue the switchover, and how to go back if a problem occurs. The AWS cutover guidance also stresses choosing an approach based on business requirements and technical constraints, testing, operational readiness and rollback planning.

This preparation is the foundation that lets the people on site start working in the new environment with confidence.

Thinking about applications and AWS infrastructure from the flow of work

SYSLABO supports both application development and AWS infrastructure, from organizing requirements through design, development, build, operations and maintenance.

When considering a cloud lift or a modernization, we decide how to proceed based on the client’s business, the history of the existing system and its relationship with the surrounding environment.

“We want to meet the maintenance deadline, but we are not ready for a full renewal.” “Our change costs keep rising, but we do not know where to start reviewing.” From stages like these, we organize the research and the information needed for decisions, and support you in making a migration and renewal plan.