Repurchase within the 6R framework: when to substitute rather than migrate Repurchase is one of the six key strategies of the AWS 6R framework for choosing cloud transformation models. Unlike the other approaches (rehost, replatform, refactor, retire, retain) that concern the management or technical redesign of the existing software, repurchase consists of completely abandoning the current on-premises application and replacing it with a SaaS solution or a native AWS managed service. This strategy is particularly relevant for general-purpose business applications, ERPs, CRMs, or collaboration tools that already exist in a modern cloud version. Rather than investing engineering resources to migrate or redesign legacy code, you substitute the software itself. This is a strategic decision that goes beyond the purely technical scope: it answers a fundamental business question: how much does it cost to keep what we have, rather than switching to something new that already exists? Repurchase therefore represents a break with the existing software estate, deliberate and planned, in exchange for a standard solution that limits technical specialization and infrastructure debt. ## Analyzing the TCO: visible and hidden costs of legacy software vs. SaaS Before deciding on a repurchase, you must first measure the total cost of ownership (TCO) of the current legacy software. This calculation includes far more than the price of an annual license. On one side, on-premises software generates infrastructure costs (physical or virtual servers, hardware maintenance, electricity, cooling, backups, business continuity plans), internal labor costs (system administrators, maintenance developers, specialized user support), hidden costs tied to technical debt (bugs that are complex to fix, obsolete dependencies, difficulty recruiting experts on old tech stacks), and finally security and compliance costs (critical patches, audits, security updates, sensitive data hosted on-premises). SaaS, on the other hand, generally presents a TCO made up of a price per user or per transaction (clearly visible and predictable), a low IT burden for administration (the vendor handles security, updates, and availability), and integration costs (onboarding, data migration, training) that are one-time. To compare honestly, you must value each cost category over the same period (usually 3 to 5 years). Legacy software that employs two full-time people for its maintenance, hosted on hardware that must be renewed every three years, often represents a TCO far higher than a SaaS costing 50 or 100 euros per user per month. Companies are regularly surprised by this comparison, because the direct costs of legacy are scattered across several budgets (IT, HR, infrastructure) while SaaS appears as a single line of expense. ## When repurchase wins over the other 6R: criteria and warning signals Repurchase is not always the best option. Certain signals should alert the CIO that this strategy is relevant, rather than spending months and considerable budgets on a technical migration. First, if the legacy application solves a GENERIC business need: payroll, accounting, CRM, project management, e-commerce, team collaboration. A SaaS already on the market probably covers 80 to 95 percent of the need, and the gap can often be absorbed by standard integrations (API, webhooks) or minor configurations. Second, if the legacy code is old, poorly documented, and unattractive to the internal team: few developers want to maintain Perl, VB6, or Delphi code. Retention and recruitment costs explode, and you start from a weak position in the labor market. Third, if you have no internal cloud skills (AWS, Kubernetes, cloud-native architectures): the technical migration will require ramp-up, or an expensive and lengthy external provider. Repurchase removes this skills barrier. Fourth, if your legacy application runs on proprietary or costly infrastructure (mainframe, highly specialized databases, dead technologies): migrating to AWS on these technologies is complex, whereas a cloud-native SaaS gets you out of that rut entirely. Finally, if business innovation depends more on access to new capabilities (AI, real-time analytics, mobility) than on mastery of the code: a modern SaaS receives these capabilities automatically via the vendor's updates, whereas a legacy application on an old version locks you in. ## The common pitfalls of repurchase and how to avoid them Repurchase seems simple in theory, but it carries concrete risks. The first pitfall is underestimating the functional complexity of the legacy. An application in production for 10 years often accumulates extensions, complex business rules, manual integrations, or workflows that no one documents because they are "obvious" to long-time users. When you test the SaaS on a few nominal cases, it seems perfect. But during the real migration, you discover hundreds of micro use cases that are not covered. To avoid this, you must run a complete functional audit of the legacy BEFORE signing the SaaS: a list of the screens, reports, parameters, and integrations. Compare each point with the SaaS. Accept that 20 percent of the needs will no longer be automated and will require a workaround. The second pitfall is the hidden cost of data migration. Moving from legacy databases to the new SaaS structures is rarely a simple export-import. The formats differ, the validation rules change, the cross-references become invalid. Too many companies accept a repurchase based on the theoretical TCO, then spend three to four times the annual cost of the software just to clean and migrate the data. Plan for this workload as a variable to be assessed independently of the license. The third pitfall is forgetting the dependencies: your legacy does not exist in isolation. It probably exchanges data with other systems (payroll, accounting, warehouse). A proprietary SaaS may have APIs, but they are limited or paid. The integrations can take two to three times as long as bringing the SaaS itself into service. The fourth pitfall is believing that repurchase reduces the IT workload. For several months after the switchover, users report anomalies and requests for adjustments. You have less "software technical maintenance" workload but more "user support and exceptions" workload. Plan for dedicated staff for six months after go-live. ## Decision roadmap: assessing repurchase step by step Making a repurchase decision cannot be a reflex: it must rest on a structured roadmap. Step 1: clearly define the business need covered by the legacy. Do not say "our CRM," but "lead management, sales pipeline, forecasting, monthly reports, integration with Mailchimp." Step 2: run a quick audit of the legacy, talking to three to five key users and the IT team. List the current pain points (slowness, bugs, costly maintenance, growth limitations) and the strengths (complex customizations, specific integrations, data archived for 20 years). Step 3: identify two to three credible SaaS candidates on the market. Do not keep just one: marketing vendors are often too optimistic about what they can do. Step 4: for each SaaS, obtain a trial license and task a power user of the legacy with testing it on their daily use cases for a week. Not a demo with the vendor's consultants, but a real test. Step 5: analyze the gaps. For each legacy need not covered by the SaaS, estimate the cost of the workaround (manual, integration, configuration) or the acceptable limit of non-coverage. Step 6: compare the legacy TCO over 3 to 5 years with the SaaS TCO (license costs, integration, training, internal support, any workarounds). Add a buffer of 20 to 30 percent for the unexpected. Step 7: if the SaaS wins, validate its long-term viability: the vendor's financial health, price trajectory, geographic support, and the security and compliance certifications you require (GDPR, SOC 2, ISO 27001). Step 8: define a minimal migration plan: what is the legacy's end date, which users switch over first, how do you handle the historical data. This roadmap takes four to six weeks and costs far less than a bad decision made quickly. ## Integrating repurchase into the overall AWS migration plan Repurchase does not exist in isolation. You probably have a portfolio of applications to migrate to AWS, and some will be repurchase, others rehost, others refactor. Repurchase must fit into a coherent strategy. First, prioritize the repurchases first in your AWS migration, before the heavy technical migrations. Why? Because they quickly free up internal IT resources (you stop maintaining a piece of software), free up IT budget (you pay for a SaaS instead of on-premises infrastructure), and deliver visible gains to the organization in three to six months. This creates momentum and credibility for the overall migration project. Second, accept that repurchase can create a dependency on a third-party vendor. You were independent hosting your legacy. With SaaS, you depend on the vendor's goodwill regarding updates, stability, and future prices. Document this decision and make sure it is a conscious trade-off, not naivety. Third, coordinate the repurchases with the other migrations in terms of centralized data. If you migrate to AWS, you will probably centralize data in a data lake or a warehouse (Redshift, Athena, and so on). Some SaaS products export data poorly or refuse bidirectional integrations. Make sure from the start that the chosen SaaS can "feed" your AWS data architecture, even minimally. Fourth, consider the impacts on RTO/RPO (Recovery Time Objective, Recovery Point Objective). With on-premises software, you control the backup. With a SaaS, the vendor controls availability and recovery. Accept these SLAs or handle a more critical piece of software through another approach (rehost on AWS or refactor).