Strategies for migrating to AWS (

Migrating to the cloud is a key step in an organization’s digital transformation, enabling greater flexibility, scalability and operational efficiency. Amazon Web Services (AWS) offers a wide range of services to support enterprises in this process. However, for a migration to be secure and effective, proper planning and execution of the various steps is essential.

In this context, the 6R model provides a proven methodology for selecting an appropriate migration strategy for various applications and IT resources. Developed by AWS, the model includes six approaches:

• Retire - disable applications that are no longer needed.

• Retain - leaving the application in its current environment.

• Rehost - moving the application to the cloud without changes (so-called “lift and shift”).

• Replatform - migration with some optimizations, such as moving the database to a managed service.

• Repurchase - changing the application to a version delivered as a service (SaaS).

• Rearchitect - rebuilding applications to take full advantage of cloud capabilities.

Choosing the right strategy depends on a number of factors, such as business objectives, technical requirements, costs, and the need to optimize security and regulatory compliance.

In this article, we will take a look at how to effectively apply the 6R model to the AWS cloud migration process, taking into account aspects of security, cost optimization and regulatory compliance.

Shortcuts

• “Six roads to the cloud” - why choosing the right migration strategy is like choosing a route for a great expedition (and why it is not worth relying on fate)?
• Rehosting (“Lift and Shift”): When does a simple “move” to the cloud make sense, and when is it just a postponement of inevitable decisions (and risks)?
• Replatforming (“Lift and Reshape”): How can minor modifications during migration yield major benefits without a complete revolution?
• Repurchasing (“Drop and Shop”): Is an off-the-shelf SaaS solution always better than an “oldie but yarny” on-premise application? When is it worth “buying” instead of “building”?
• Refactoring/Rearchitecting: When is a major application redesign for the cloud an investment that really pays off (and how not to overdo it)?
• Retiring and Retaining: Why sometimes the best migration strategy is… not migrating (or getting rid of unnecessary ballast)?
• As your experienced cloud pilot, how does nFlo help you select and execute the optimal (and safe!) migration strategy for each of your applications?
• Key findings: Strategies for migrating to AWS (“6 R’s”).

“Six roads to the cloud” - why choosing the right migration strategy is like choosing a route for a great expedition (and why it is not worth relying on fate)?

The decision to migrate to the AWS cloud is the beginning of an exciting yet challenging expedition to modernity, flexibility and innovation for any organization. However, as before any great expedition, it is crucial not only to pack the right equipment (resources and technology), but above all to plan the route carefully. In the world of cloud migrations, one of the most popular and useful “maps” is the “6 R’s” model popularized by AWS. These are six fundamental strategies, six different paths we can follow as we move our applications and data to the cloud. Why is choosing this right path (or combination of paths) so important, and why is it not worth relying on chance here?

Imagine that you plan to climb a high peak. You have several trails to choose from - some are gentle and well-traveled, but lead to the summit by a circuitous route and do not offer spectacular views. Others are steep, requiring specialized equipment and experience, but take the shortest route and guarantee an unforgettable experience. Still others may turn out to be dead ends or lead through dangerous terrain. The choice of route will depend on your goals (do you want to summit as quickly as possible or enjoy the views?), your capabilities (fitness, equipment, budget) and the nature of the summit itself (its difficulty, weather conditions).

The same is true for migrating to AWS. Each of the six strategies - Rehost, Replatform, Repurchase, Refactor/Rearchitect, Retire, Retain - has its own specific characteristics, advantages, disadvantages, costs, risks and, crucially, implications for the security and future management of your environment. Choosing the right strategy for each of your applications and systems, based on an in-depth analysis of their characteristics, business objectives and requirements, is absolutely critical to the success of the entire transformation.

Relying on fate or choosing strategies “on the spur of the moment” can lead to a number of problems:

• Suboptimal use of cloud capabilities: Choosing a strategy that is too simple (e.g., lift-and-shift for everything) can cause you to miss the full potential of AWS’s flexibility, scalability and native services, and your cloud bills to be higher than expected.

• Performance and compatibility issues: Some applications, moved to the cloud without appropriate modifications, may run inefficiently or encounter compatibility problems.

• Security vulnerabilities: Moving existing security issues from the on-premises environment to the cloud or inadequately securing new cloud configurations is an easy path to incidents. Implementing a robust firewall strategy and proper network segmentation from the start is essential for any migration approach.

• Unmet business goals: If your migration strategy is not consistent with your goals (e.g., you want innovation, and you choose only rehosting), you may not achieve the expected benefits.

• Unnecessary costs and delays: The wrong choice of strategy at the outset can lead to the need for costly revisions and rework in the future.

That’s why it’s so important, before embarking on this “cloud journey,” to take the time to carefully study the map - that is, to understand the various “6 R’s” strategies - and consciously choose the ones that will best lead you to your intended goal - a secure, effective and valuable presence in the AWS cloud. This is not relying on fate, but strategic planning for success.

📚 Read the complete guide: Cloud Security / AWS: Public cloud security - AWS, Azure, best practices

Rehosting (“Lift and Shift”): When does a simple “move” to the cloud make sense, and when is it just a postponement of inevitable decisions (and risks)?

The rehosting strategy, fondly called “Lift and Shift,” is often seen as the easiest and fastest way to the AWS cloud. It involves, in a nutshell, moving existing servers and applications from your on-premises (or other cloud) environment to an Amazon EC2 instance with virtually no changes to their architecture or code. It’s like packing all your possessions into a container and transporting them to a new apartment, without remodeling or redecorating. Sounds tempting, doesn’t it? It can indeed be a sensible solution in some situations, but you also need to be aware of its limitations and potential pitfalls.

When might “Lift and Shift” be a good idea?

• When time and speed of migration are of the essence: If you’re facing the need to quickly leave your own server room (e.g., due to the end of a lease) or need to immediately increase the scalability of existing applications without redesigning them, rehosting can be the fastest way to achieve these goals.

• For legacy applications that can’t or won’t pay to be modified: Do you have legacy systems in your portfolio whose source code is inaccessible, documentation sparse, and knowledge of their operation limited to a few people? Trying to refactor them could be too risky or costly. In that case, “lift-and-shift” may be the only viable option to move them to a more flexible cloud environment.

• For Commercial Off-The-Shelf (COTS) applications that are not optimized for the cloud: If you’re using off-the-shelf software from third-party vendors that doesn’t offer native integration with cloud services, rehosting on EC2 instances can be a way to get them up and running on AWS.

As the first step in a longer transformation strategy: Sometimes rehosting is treated as a transitional phase - quickly moving applications to the cloud to gain immediate benefits (e.g., reducing hardware maintenance costs) and then, already in an AWS environment, gradually optimizing, refactoring or replacing them with more modern solutions.

When is “Lift and Shift” just a postponement of inevitable decisions (and risks)?

Note, however, that rehosting, while fast, does not solve the fundamental architectural and performance problems of the applications being moved. If your application was inefficient, poorly optimized or difficult to manage in an on-premises environment, it will likely remain so even after moving it to EC2 instances. The cloud is not a magic wand that will automatically fix all problems.

Organizations should also consider engaging a SOC to maintain continuous security monitoring throughout and after the migration process. What’s more, you’re also moving existing vulnerabilities and security issues. If your server’s operating system was an unpatched “sieve” and your application full of vulnerabilities, simply moving them to AWS won’t change anything unless you take additional steps to secure them in the new environment. The responsibility for the security of the operating system, patches, application configurations and data on EC2 instances still rests with you.

The “Lift and Shift” strategy also doesn’t allow you to take full advantage of the potential of native AWS cloud services, such as managed services (RDS, S3, Lambda), auto-scaling, or advanced analytics tools. Your applications will continue to operate in a manner similar to how they worked on-premises, which may limit your ability to innovate and optimize costs in the long run.

Therefore, while rehosting can be a useful tactic in certain situations, it should rarely be the target strategy for all your applications. Often it is merely a deferral to the need to make more fundamental decisions about modernizing, refactoring or replacing legacy systems with solutions better suited to the cloud era. The key is to make a conscious choice and understand that “moving” is only the beginning of the journey, not the end.

Replatforming (“Lift and Reshape”): How can minor modifications during migration yield major benefits without a complete revolution?

Between the simple “Lift and Shift” and the complicated and time-consuming application refactoring lies an interesting AWS cloud migration strategy known as replatforming, sometimes referred to as “Lift and Reshape” or “Lift and Optimize.” It’s an approach that can be likened to moving to a new apartment, during which you decide not only to move old furniture, but also to lightly refresh it, repaint it or replace some items with newer ones that better fit the new interior. Replatforming involves moving existing applications to the cloud with some, usually minor, modifications at the platform or infrastructure level to better leverage the native capabilities of AWS, but without fundamentally changing the architecture of the application itself.

What might these “minor modifications” consist of? The most common example is migrating databases from your own servers (on-premises or on EC2 instances) to AWS-managed services such as Amazon RDS (Relational Database Service) or Amazon Aurora. Instead of managing the database server’s operating system, patching, backups or replication ourselves, we delegate these tasks to Amazon. We are still responsible for the database schema, query optimization and data security, but we are relieved of many time-consuming administrative tasks. Similarly, we can move our web application from our own Apache or Nginx server on EC2 instances to a more flexible and managed environment like AWS Elastic Beanstalk, which automates the deployment, scaling and monitoring of applications.

Other examples of replatforming may include:

• Changing the operating system to one more optimized for the cloud (e.g., switching from a commercial Unix system to a Linux distribution supported by AWS).

• Using AWS services to support specific application functions, such as moving static file storage to Amazon S3, using Amazon SQS for message queues, or Amazon ElastiCache for data caching.

• Containerize the application using Docker and run it on services such as Amazon ECS (Elastic Container Service) or Amazon EKS (Elastic Kubernetes Service), which increases portability and simplifies management.

When is replatforming worth considering?

• When you want the quick benefits of AWS managed services (e.g., less administrative burden, better scalability, higher availability) without having to completely rewrite your application.

• When your application has some performance or scalability issues that can be solved through minor modifications and the use of specific cloud services.

• When you want to upgrade the platform on which your application is running, such as moving to a newer version of the database or application server, and AWS managed services offer this possibility “out of the box.”

• As an intermediate step before full refactoring - replatforming can be a way to stabilize an application in the cloud and prepare it for deeper architectural changes in the future.

What about security with replatforming? This strategy offers some security benefits, as some of the responsibility (e.g., for patching the managed service’s operating system) is taken over by AWS. However, you still need to take care of the secure configuration of the AWS services you use (e.g., appropriate access rules for RDS, data encryption in S3, IAM policies for containers). It is also important to understand the shared responsibility model for each of the services you use. Replatforming is a good time to review and strengthen the authentication and authorization mechanisms in the application itself, even if its core remains unchanged.

Replatforming is a pragmatic approach that finds the golden mean between the speed and simplicity of rehosting and deep refactoring. It’s a smart way to make your “old furniture” not only look good in your new cloud-based apartment, but also more functional and easier to maintain.

Repurchasing (“Drop and Shop”): Is an off-the-shelf SaaS solution always better than an “oldie but yarny” on-premise application? When is it worth “buying” instead of “building”?

In the IT world, we often face a dilemma: develop and maintain our own “tailor-made” solutions, or take advantage of off-the-shelf products offered on the market? The cloud migration strategy known as repurchasing, sometimes referred to as “Drop and Shop,” is precisely the answer to this dilemma. It involves completely replacing the existing application we planned to migrate with a new, off-the-shelf solution, most often offered in a SaaS (Software-as-a-Service) model by a third-party provider. It’s like deciding that instead of transporting an old, worn-out piece of furniture to a new apartment and trying to refurbish it, we simply buy a new, more functional and more modern counterpart.

When might such a radical change be the best option?

• When your current application is outdated and inefficient: Do you have a CRM system that still remembers the days of floppy disks, an ERP system whose interface scares users away, or a project management tool that can’t keep up with the needs of your team? If maintaining, developing and integrating such an application is generating more costs and frustration than benefits, it may be time to say “goodbye” to it and look around for a modern SaaS alternative.

• When there are mature, specialized SaaS solutions available on the market that perfectly suit your needs: SaaS providers often offer very sophisticated, feature-rich and constantly evolving platforms for specific business areas (e.g., the aforementioned CRM, ERP, HR systems, marketing automation tools, e-commerce platforms). If such an “out of the box” solution covers 80-90% of your requirements, and its subscription cost is acceptable, building or migrating an old system on your own may simply not make sense.

• When you want quick access to new features and innovations: SaaS providers typically develop their products very rapidly, regularly introducing new features, integrations and enhancements. By using such a solution, you gain access to these innovations without having to incur your own R&D costs.

• When you want to reduce the burden of maintaining infrastructure and applications: In a SaaS model, the provider is responsible for maintaining servers, databases, software, security and updates. This allows your IT team to focus on more strategic tasks that directly support your business goals.

What about security with a repurchasing strategy? When you choose a SaaS solution, you are transferring much of the responsibility for security to the provider’s shoulders. It is they who must take care of protecting the infrastructure on which the application runs, the security of the software itself, and protecting your data stored on their systems. That’s why it’s absolutely crucial to conduct careful security due diligence on a potential SaaS provider before making a decision. What should you pay attention to?

• Certifications and standards compliance: Does the vendor have recognized security certifications (e.g. ISO 27001, SOC 2)? Is its solution compliant with the regulations that apply to you (e.g., RODO, HIPAA, PCI DSS)?

• Security and data protection policies: What data encryption mechanisms (at rest and in transit) does the provider use? How does it manage encryption keys? What are its incident response procedures? Where is your data physically stored?

• Authentication and authorization mechanisms: Does the SaaS solution support strong authentication (e.g., MFA)? Does it allow for granular management of user privileges? Is it possible to integrate with your existing identity management system (e.g., via SAML or OIDC for SSO)?

• Terms of Agreement (SLA): What are the guaranteed levels of service availability? What are the liability rules in case of a security incident? What happens to your data after the contract ends?

A repurchasing strategy can be extremely beneficial, allowing you to quickly get rid of outdated systems and gain access to modern, functional solutions. However, the key to success here is to choose your vendor wisely and understand exactly what security and compliance aspects remain on your side (e.g., managing user accounts, configuring policies specific to you within the SaaS platform). This is not a total surrender of responsibility, but a conscious partnership.

Refactoring/Rearchitecting: When is a major application redesign for the cloud an investment that really pays off (and how not to overdo it)?

The Refactoring/Rearchitecting strategy is the most advanced, time-consuming and often the most costly of the six ways to migrate to the AWS cloud. It involves fundamentally redesigning or completely rewriting an existing application to take full advantage of the native capabilities, architecture and services offered by the cloud platform. It’s no longer a simple “move” or “light facelift” - it’s like building a brand-new smart home on (or even next to) the old foundations, using the latest technologies and materials. When is such a deep transformation worth the price and effort, and when can it be form over substance?

When is it worth investing in refactoring/rearchitecting?

• When your application is strategically important to the business, but its current architecture is outdated, monolithic and stifles development: If you have a key system on which your competitive advantage depends, but it’s difficult to scale, expensive to maintain, and takes ages to introduce new features, refactoring for the cloud (e.g., toward microservices architecture, serverless, containerization) may be the only way to give it a “second life” and provide long-term value.

• When you want the maximum scalability, flexibility and resiliency that the cloud offers: AWS native services such as auto-scaling, load balancing across multiple availability zones, managed NoSQL databases (e.g., DynamoDB) or Lambda functions allow you to build applications that are extremely powerful, resilient and can dynamically adapt to changing workloads. Taking full advantage of these capabilities, however, often requires deep changes to the architecture.

• When you want to significantly reduce operating costs in the long term by optimizing for the cloud: a well-designed, “cloud-native” application can be much cheaper to maintain than its monolithic counterpart ported by the lift-and-shift method. Leveraging serverless services (you only pay for the actual calls), auto-scaling (you only pay for the resources you need) or optimized storage services can yield significant savings.

• When you want to introduce innovative features based on advanced AWS services: the Amazon Web Services cloud is not just servers and databases. It’s also access to powerful tools in machine learning (Amazon SageMaker), Big Data analytics (EMR, Redshift), Internet of Things (AWS IoT) or stream processing (Kinesis). Using these services to build new, disruptive functionality into your application often requires refactoring.

How not to overdo it and avoid “burning through” the budget?

Refactoring is a powerful tool, but also a double-edged sword. If approached without a proper plan and control, it can easily spiral out of control, consuming huge amounts of time and money and failing to deliver the expected results (“Big Bang Rewrite” is often a recipe for disaster).

• Start with a thorough business and technical analysis: Do the benefits of refactoring really outweigh the costs and risks? Is the application strategic enough to justify such a large investment?

• Use an iterative and incremental approach: Instead of trying to rewrite the entire application at once, break it down into smaller, manageable modules or services and refactor them incrementally (e.g., using the “Strangler Fig Application” pattern). This allows you to deliver value faster, gather feedback and minimize risk.

• Focus on the areas that will benefit you the most: Not everything needs to be refactored. Identify the parts of the application whose modernization will yield the greatest return on investment (e.g., improving the scalability of a key module, reducing the cost of the most resource-intensive function).

• Use proven architectural patterns for the cloud: Such as microservices, event-driven architecture, and serverless. Don’t reinvent the wheel.

• Remember security at every stage (“Security by Design”): Refactoring is a great opportunity to build security best practices directly into new application architecture and code. Take advantage of AWS’ native security mechanisms (IAM, KMS, Security Groups, etc.) right from the start. A virtual CISO can provide strategic security guidance throughout the refactoring process to ensure compliance and risk management are built into the new architecture.

Refactoring/rearchitecting is a strategy for brave and conscious organizations that want to take full advantage of the transformative power of the cloud. It’s an investment in the future that, if planned and executed wisely, can yield spectacular results.

Retiring and Retaining: Why sometimes the best migration strategy is… not migrating (or getting rid of unnecessary ballast)?

In the heat of planning a “big move” to the AWS cloud, it’s easy to fall into the trap of thinking that absolutely every application and every system must be moved. Meanwhile, two of the six migration strategies, often somewhat overlooked but extremely important from an optimization and risk management perspective, are Retiring and Retaining. After all, sometimes the best decision we can make is to consciously abandon the migration of certain elements or even get rid of unnecessary technological ballast altogether.

Retiring (Withdrawal) - The art of saying “goodbye.” During the detailed inventory of the application portfolio that we conduct at the beginning of the migration planning process, we often find that hidden in the depths of our infrastructure are systems that hardly anyone remembers exist. Applications that were once used, but are now redundant because their functionality has been taken over by other, more modern tools. Systems that generate maintenance costs (licenses, servers, support) and no longer bring any real business value. Or simply applications that are so outdated and incompatible with modern standards that any attempt to migrate or upgrade them would be uneconomic and too risky.

In such situations, the “Retiring” strategy is most appropriate. It is a conscious decision to disable and remove such applications from our infrastructure. The benefits are obvious:

• Cost Reduction: Eliminate expenses associated with maintaining unnecessary systems.

• Simplifying the IT environment: Fewer systems to manage, monitor and secure.

• Reducing the attack surface: Any running application, especially one that is old and not easy, is a potential attack vector. Its withdrawal reduces this risk.

• Freeing up resources: The IT team’s time and energy that has been spent maintaining “zombie applications” can be redirected to more strategic initiatives, including migrating and developing the systems that really matter.

Of course, the process of decommissioning an application must be carefully planned. Make sure that no critical data is lost (archiving), that there are no hidden dependencies that could disrupt other systems, and that users (if there are any still) are properly informed and possibly transferred to other solutions.

• Retaining (Leaving in the current place) - Sometimes “old” means “good” (or “necessary”). Not every application needs to go to the cloud. There are situations where the best strategy is to deliberately leave certain systems in an existing on-premises environment or in a private cloud. When can such a decision be justified?

• When the application is running stably, efficiently and securely in the current environment, and there would be no significant business or technical benefit to migrating. If something works well and doesn’t generate problems, there’s no point in moving it just for the sake of the idea of “being in the cloud.”

• When there are very specific requirements for performance, latency or integration with specialized on-premises hardware that cannot be easily or cost-effectively implemented in the public cloud (e.g., industrial control systems, some laboratory systems).

• When very stringent data sovereignty or data residency requirements are in place that mandate the storage and processing of specific information in a specific geographic location or on dedicated infrastructure, and public cloud offerings do not fully meet these requirements.

• When software licensing costs are unfavorable in a cloud model, or when there are long-term contracts with vendors that make migration uneconomical at the time.

• As part of a hybrid cloud strategy, where some workloads intentionally remain on-premises and some are migrated to the cloud, and the two environments are integrated with each other.

However, the decision to leave the on-premises system does not mean that it can be forgotten. It still needs to be properly managed, monitored and secured in accordance with best practices. It is also important to regularly review whether the rationale behind the decision is still valid.

Retiring and Retaining strategies are proof that smart cloud transformation is not blindly following a fad, but informed, analytics-driven decisions to optimize the entire IT environment in terms of business objectives, costs and risks. Sometimes the biggest benefit is precisely what we won’t do.

As your experienced cloud pilot, how does nFlo help you select and execute the optimal (and safe!) migration strategy for each of your applications?

Choosing the right AWS migration strategy from among the six available “routes” (the “6 R’s”) for each of your applications and systems is a complex task, requiring not only an in-depth knowledge of cloud technologies, but also an excellent understanding of your business goals, the technical specifics of each workload, and your risk appetite. At nFlo, we play the role of your experienced pilot on this cloud journey - a navigator who will help you not only choose the best and safest route for each “passenger” (your application), but also efficiently and confidently get the entire fleet to its destination.

Our support in this crucial process is based on several fundamental steps:

1. a collaborative, in-depth analysis of your application portfolio (Application Portfolio Assessment). No two companies are the same and no two applications are the same. That’s why we start by working closely with your team to thoroughly inventory and understand each application you are considering for migration. We analyze its architecture, the technologies used, dependencies on other systems, business criticality, current maintenance costs, performance or security issues, and your development plans associated with it. It’s like a detailed review of any aircraft before takeoff.

2 Map applications to optimal “6 R’s” strategies in the context of your goals. Based on the information gathered, we work with you to assign each application to one (or sometimes a combination) of six migration strategies. We help you answer the key questions: Is this application worth simply moving quickly (“Rehost”)? Will minor platform changes (“Replatform”) bring significant benefits? Or is it time to replace it completely with a SaaS solution (“Repurchase”) or fundamentally rebuild for the cloud (“Refactor”)? Or are some systems better off simply phased out (“Retire”) or deliberately left on-premises (“Retain”)? Our recommendations are always based on hard data and your business priorities.

3 Evaluate the security and compliance implications for each chosen strategy. Each of the “6 R’s” carries different security and compliance implications. “Lift-and-shift” can relocate existing vulnerabilities, refactoring requires “by design” security to be built in, and choosing SaaS means you need to evaluate vendor security. Our cybersecurity experts analyze these implications for each application and help design appropriate controls and risk mitigation strategies that will be an integral part of the migration plan.

4 Create a detailed migration roadmap and implementation plan. Once the strategies for each application are selected, we help create a consistent, prioritized roadmap for the entire migration. We determine the order in which each workload should be moved (often starting with the less critical ones to gain experience and minimize risk), define timelines, resources needed, migration tools and success criteria for each stage.

5 Support in the safe and efficient implementation of migration. Our team can take an active role in the migration itself, using best practices and proven AWS tools for data and application transfer. We make sure that every step is implemented as planned, with the highest security standards and minimal disruption to your business.

6. post-migration optimization and management. Our role doesn’t end with “getting you to the cloud.” We also help you optimize your new environment for cost, performance and security, as well as implement effective management and monitoring processes so you can reap the full benefits of your AWS investment.

At nFlo, we do not offer a one-size-fits-all migration scheme. We understand that every journey to the cloud is different. That’s why our goal is to be your flexible, knowledgeable and trustworthy partner to help you navigate through the complexity of the “6 R’s” strategy, choose the best path for your business and safely reach your destination of a modern, efficient and resilient AWS cloud infrastructure.

Key findings: Strategies for migrating to AWS (“6 R’s”).

Aspect	Key information
The importance of choosing a migration strategy (“6 R’s”)	Choosing the right path (Rehost, Replatform, Repurchase, Refactor, Retire, Retain) for each application is critical to the success of the transformation, optimizing costs, security and meeting business goals. Avoiding a “one strategy fits all” approach.
Rehosting (“Lift and Shift”)	Quickly “move” an application to AWS EC2 without major changes. Sensible for quick on-premise cost reduction, legacy applications or as a first step. Risks: transfer of existing problems, incomplete use of cloud potential. OS and application security on the client side.
Replatforming (“Lift and Reshape”)	Application portability with some platform modifications (e.g., migration to Amazon RDS, Elastic Beanstalk, containerization). Benefit from AWS managed services without complete refactoring. Part of the responsibility for platform security is assumed by AWS.
Repurchasing (“Drop and Shop”)	Replacing an existing application with an off-the-shelf SaaS solution. Beneficial for outdated systems when there is a better alternative on the market. Key security and compliance assessment of the SaaS provider. Security responsibility largely on the provider’s side.
Refactoring / Rearchitecting	Thorough application redesign for native cloud services (microservices, serverless). Highest potential for scalability, flexibility and cost optimization. Requires a “security by design” approach. Most complex and costly strategy.
Retiring and Retaining	Retiring: Eliminating unnecessary, redundant or unprofitable applications (cost and risk reduction). Retaining: Consciously leaving some systems on-premises (e.g., due to specific requirements, licensing costs, hybrid strategy).
Support nFlo in selecting and implementing the “6 R’s” strategy	In-depth analysis of the application portfolio, mapping to optimal strategies in the context of the client’s goals, assessing security implications for each strategy, creating a migration roadmap, supporting secure implementation and post-migration optimization. Experienced “cloud pilot.”

Frequently Asked Questions (FAQ)

What are the 6Rs of AWS cloud migration?

The 6Rs are six migration strategies defined by AWS: Rehost (lift and shift), Replatform (lift and reshape), Repurchase (drop and shop for SaaS), Refactor/Rearchitect (rebuild for cloud-native), Retire (decommission), and Retain (keep on-premises). Each strategy suits different application types, business goals, and risk profiles.

How do I choose the right migration strategy for my application?

The choice depends on several factors: the application’s business criticality, its current architecture and technical debt, your timeline and budget, performance and scalability requirements, and compliance needs. A thorough application portfolio assessment that evaluates each workload against these criteria is the recommended starting point.

How long does a typical AWS cloud migration take?

Migration timelines vary widely based on scope and strategy. A simple rehost of a single application can take weeks, while a full portfolio migration using mixed strategies typically spans 6-18 months. Refactoring projects for complex applications typically take 12 months or more. Proper planning and a phased approach help manage timelines effectively.

How much does migrating to AWS cost?

Costs depend on the chosen strategy and scale. Rehosting is the least expensive upfront but may lead to higher ongoing cloud bills. Refactoring requires significant investment in development but yields long-term savings through optimized cloud usage. Organizations should factor in assessment, migration tools, training, and potential downtime costs alongside infrastructure expenses.

What is the difference between lift and shift and refactoring?

Lift and shift (rehost) moves applications to the cloud without code changes, offering speed but limited cloud optimization. Refactoring involves redesigning the application architecture to leverage cloud-native services like serverless computing and managed databases. Refactoring costs more upfront but delivers better scalability, performance, and long-term cost efficiency.

---

Related Terms

Learn key terms related to this article in our cybersecurity glossary:

• CSPM (Cloud Security Posture Management) — CSPM (Cloud Security Posture Management) is a category of cloud security tools…
• Network Security — Network security is a set of practices, technologies, and strategies aimed at…
• Cloud Environment Security — Cloud environment security refers to the technologies, procedures, policies,…
• Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
• Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…

---

Learn More

Explore related articles in our knowledge base:

• Migrating to the AWS cloud: a roadmap for a safe, efficient and painless transition
• AWS vs Azure vs Google Cloud - A comparison of public cloud leaders
• Cloud Migration Strategies: Best Practices, Challenges and Cost Optimization
• How to avoid the most common mistakes when migrating to the cloud?
• Migrating to the cloud step by step - A complete guide

---

Explore Our Services

Need cybersecurity support? Check out:

• Cloud Security Audit - cloud environment security assessment
• AWS Migration - secure cloud migration
• AWS Management - comprehensive AWS services