Refactor and rearchitect: two modernization paths beyond rehost
Refactor and rearchitect are two strategies that sit at the heart of cloud modernization. Unlike rehost (which simply shifts the existing application to the cloud without modification), both approaches accept that the application must evolve to take advantage of the cloud. But they differ radically in scope and business impact. A refactor applies light, targeted changes to an existing architecture to optimize its cloud execution: for example, moving from a self-managed database to an AWS managed database, or splitting a monolithic application into a few microservices without rewriting the whole thing. A rearchitect, by contrast, involves a complete restructuring of the application to turn it into a genuine cloud-native system, with a breakdown into microservices, containerization, distributed state management, and often an update of the technology stacks. For an organization already stabilized on AWS with a substantial technical backlog, this distinction determines not only cost and timeline, but also the risk and the load of a transition. Understanding when to choose one or the other is therefore critical before committing.
Refactor: modernizing an existing architecture without upheaval
The refactor is the most gradual strategy. The core idea is to preserve the business logic and the overall architecture of the application while adapting it so that it makes better use of cloud capabilities. This can mean replacing a self-managed PostgreSQL database with Amazon RDS or Aurora, extracting a monolithic cache layer into ElastiCache, or splitting part of a monolithic application into Lambda without touching the core of the system. The changes stay localized and incremental. The refactor is particularly well suited to applications that already work correctly in terms of business logic, but that suffer from operational problems or costs: an AWS bill that spikes because a database runs at full capacity 24/7, insufficient resilience because the application does not tolerate interruptions, or operational technical debt tied to the manual management of infrastructure that should have been automated long ago. The benefits of a refactor are many. First, the business risk is low: since the business logic changes little, regression testing is less voluminous and migration phases can be progressive, or even handle a gradual cutover by percentage of traffic. Next, timelines are measured: a good internal team or an experienced partner can often deliver a refactor in 3 to 6 months for a moderately sized application. Finally, costs are more predictable because the engineering effort stays bounded. However, a refactor does not solve deep architectural problems. If the application is built on major antipatterns (distributed state management, tight coupling between components, vertical rather than horizontal scaling), a refactor will only add bandages. It is in these cases that a rearchitect must be considered.
Rearchitect: complete restructuring for cloud-native
The rearchitect is the opposite approach: you accept a substantial overhaul of the application to make it cloud-native from the ground up. This means rethinking the breakdown into components (migration to microservices or decoupled services), adopting distributed state management via queues or NoSQL databases, containerizing each service, and often modernizing the technology stacks: moving from Java 8 to Java 17 on Spring Boot 3, migrating a frontend layer to a modern SPA, or replacing business logic written in PL/SQL with Python Lambda functions. The rearchitect is not a fad, it is a response to real architectural limits. An application that grows quickly, that must support 10 times more load in 18 months, that involves distributed teams needing to deploy independently, or that suffers from slow deployments (6 months to ship a simple feature), is a natural candidate for a rearchitect. Because once cloud-native, the application can evolve service by service, deploy each service several times a day, and scale business areas independently of the others. The long-term benefits are immense: transformed business velocity, improved resilience (a service can go down without stopping the application), and a natural cost-to-load fit (paying for the CPU actually used, not for a VM on standby). However, the rearchitect is also the most costly and riskiest path. Timelines easily stretch to 12 to 24 months for a large application, the engineering load is heavy, business teams must understand and accept that "the system will be less performant for a while" before regaining productivity, and there is a real risk of scope creep that sends the bill off the rails. In addition, during the overhaul, the old application must be kept in production. Finally, a successful rearchitect requires a partner or an internal team that is very experienced in cloud architecture and capable of making difficult architectural decisions without dithering.
Decision matrix: refactor or rearchitect based on your application profile
Choosing between refactor and rearchitect is not an abstract architectural question. It is a decision based on several concrete criteria: business complexity, technical complexity, risk appetite, and business timelines. Let us start with business complexity. If your application supports simple, stable business flows (a basic CRM, a billing application, a classic management portal), a refactor is generally enough. The goal is not to revolutionize the business, it is to run the existing system more efficiently and more cheaply. On the other hand, if you operate a B2B multi-tenant platform that must support thousands of different customers, each with slightly different workflows, or if your business requires fine-grained customization per customer and rapid evolution of business rules, the rearchitect becomes necessary: you need the flexibility of a finely decoupled architecture. Next, look at technical complexity. An application built with modern patterns (a REST API, a well-schematized relational database, a clear separation between layers), and that does not suffer from deep coupling, refactors easily. But a monolithic application of 500,000 lines of code with a database that contains 200 tightly linked tables, direct calls to the file system, and business logic intertwined with the network layer, is a rearchitect candidate: you have to unpack it, so to speak. The timeline factor also plays a role. If your business stakeholders can wait 18 months before seeing the benefits of the change, a rearchitect is feasible and recommended for high-stakes situations. If leadership expects tangible results (cost reduction, performance improvement) within 6 months, a refactor is what you are looking for. Finally, assess your risk appetite. A well-executed refactor has a very low failure rate (less than 5% chance of a critical production problem). A rearchitect, even with a good partner, remains a riskier undertaking: you have to be ready to handle technical or business surprises that slow the project down. Use the 6R matrix provided by your overall cloud strategy: it helps place each application on a diagram showing technical complexity on the x-axis, business criticality on the y-axis, and the clear trajectory toward refactor or rearchitect (or another model such as rehost or repurchase) follows from it.
Blockers and dependencies: the crucial step before committing
Refactor and rearchitect often run into the same obstacles: dependencies. Before committing to either strategy, you must map these dependencies, otherwise you discover the problem in the middle of the project and timelines explode. A dependency can be technological (the application calls an obsolete proprietary DLL), business-related (the application must remain compatible with a legacy system you cannot migrate), network-related (the application depends on a VPN connection to an on-premise data center to access a specific table), or organizational (two applications share code, modified independently by two teams). For a refactor, dependencies are generally manageable. You can create an abstraction over the DLL, encapsulate the call to the legacy system via an API, or maintain a small network bridge for a few months. The impact is localized and manageable. For a rearchitect, dependencies become critical because you are restructuring everything. If you rearchitect an application A that depends on an application B not yet migrated, you have two painful choices: either you maintain point-to-point coupling (which cancels out part of the benefits of the rearchitect), or you must rearchitect B in parallel (which multiplies the complexity and timelines). This is why the preliminary work of decoding dependencies is crucial. A quick audit (2 to 3 weeks) makes it possible to identify which applications can be refactored independently, which require a preliminary decoupling effort (which can be done at the same time as the refactor), and which are so linked that they demand a coordinated migration. This audit also reveals "surprise dependencies": static modules shared between five applications, secrets stored hard-coded in code, or direct database calls that bypass the ORM. These discoveries will change the migration plan. A good AWS partner will know how to run this audit quickly and propose pragmatic solutions (partial refactor with temporary coupling, gradual decoupling in parallel with the refactor, etc.) rather than waiting for an architectural purity that would cost an extra six months.
Best practices for a successful refactor and rearchitect
Whether it is a refactor or a rearchitect, certain execution principles make the difference between a project delivered on time and a project that goes off the rails. First, iteration and incrementality. No refactor or rearchitect should be an overnight switch. Choose a low-criticality branch of the application, migrate it, validate it in production with real traffic for one to two weeks, then move on to other branches. This approach reveals problems early and limits the damage in case of error. For a refactor, this means migrating component by component. For a rearchitect, it means breaking the migration into phases: first the stateless and non-critical services, then the key business services, and finally the most coupled services. Next, observability and testing. Before migrating anything, equip the current application with good instrumentation (structured logs, distributed traces, business metrics) to fully understand its behavior in production. During the migration, this instrumentation lets you compare the old and the new: response times, errors, CPU hotspots. After the migration, it alerts you to anomalies in real time. Testing is just as critical: unit tests of course, but also integration tests (checking that the new service talks correctly to the database), and above all load tests (checking that your new architecture supports business peaks). For a rearchitect, load tests often reveal distributed state or resource contention problems that are not visible in development. Finally, communicate relentlessly with your business and operations teams. A migration that succeeds technically but that internal users do not understand quickly becomes a problem: loss of trust, massive support requests, pressure to revert to the old system. Involve business teams on the acceptance criteria ("after the refactor, the report export must take less than 30 seconds"), and support teams on the operational changes ("the new system monitors ElastiCache for performance, not the application logs"). When everyone understands why the migration is happening and what is changing, adoption is much smoother.
Realistic costs and timelines for each approach
A question every infrastructure manager asks: how much does it cost and how long does it take? The figures vary enormously depending on complexity, but here are orders of magnitude based on real migrations at AWS customers. A refactor of a moderately sized monolithic application (50,000 to 200,000 lines of code, 10 to 20 distinct business screens, a classic database) generally takes between 3 and 6 months with a dedicated team of 4 to 6 people (developers, architects, QA). The cost is on the order of 250,000 to 500,000 euros for an SMB or mid-market company, cheaper if you use a fixed-price AWS partner (who absorbs the timeline overruns) and keep a good share of the effort in-house. A rearchitect of the same application can take 12 to 18 months, with a larger team (8 to 12 people including several senior cloud architects), and cost 1 to 2 million euros. If the application is very large (1 million lines), very critical (zero tolerance for latency), or very integrated (hundreds of dependencies), the rearchitect can stretch to 24 months and beyond. These timelines assume a good internal team and a competent partner. A precise estimate, however, requires a detailed assessment of the target application: without it, any announced budget remains a rough estimate. So scope the perimeter and assess the existing system before committing to a firm cost or timeline.