From Disaster Recovery to Production: VVN Group's Zero-Downtime SAP Migration to AWS

About project

The Challenge

The SAP system was healthy. The infrastructure underneath it was expensive, and every year it got harder to justify.

• Capacity had to be bought a year early. Adding a brand, a category or a country meant sizing hardware for where the business would be in twelve months, then paying for that headroom from the day it arrived. The group had been growing faster than that cycle allows.
• Peak was permanent. The landscape was specified for the busiest weeks of the year. For the rest of it a large share sat idle, and there was no mechanism to hand any of it back.
• Non-production cost roughly what production cost. Development and QA ran on their own servers, sized to match, and were in use during office hours at best. Switching them off was not an option, because nothing guaranteed they would come back.
• A refresh was coming. Servers bought together age together, and the group was looking at one large capital decision covering the entire ERP estate at once.
• Real disaster recovery meant buying the landscape twice. A recovery site is a second set of hardware in a second location. The group had backups instead. It had never executed a recovery, and the recovery copy sat next to the primary.
• Basis time went on infrastructure. Storage, firmware, capacity planning, refresh scheduling. Effort that could have gone into the business went into keeping the platform alive.
• There was no window to fix any of it. Distribution runs seven days a week against a 24-hour delivery promise, and since 2017 a production line has run on the same system. Whatever the answer was, it could not involve stopping.

Technology & Approach

Disaster recovery came first

The group did not open with a request to migrate. It asked what it would cost to have somewhere to fail over to.

On AWS that is a small project rather than a capital one. We replicated the landscape into a target environment in eu-central-1, wrote the failover procedure, then ran the failover for real and timed it. Six weeks after kickoff the group had a recovery position it had actually tested, for a fraction of what a second data centre would have cost.

It stayed that way for seven months, and during those seven months the target was doing a second job: proving itself. By the time anyone asked whether production could move onto it, the environment had been holding real data and surviving real drills for over half a year. When the migration came it was not a jump onto new infrastructure. It was a promotion of infrastructure that had already been running.

Sizing it on what SAP was actually doing

The usual way a project like this loses its business case is by copying the on-premises specification into EC2. Five years of accumulated over-provisioning comes across with it, and the group starts paying monthly for headroom it had already paid for once.

We sized from workload instead. EarlyWatch Alert reports and twelve months of ST03N statistics gave the real CPU, memory and response profile for each instance. Every instance family was checked against SAP Note 1656099, which is the binding statement of what SAP supports on AWS; nothing went onto an uncertified type, non-production included.

Production and non-production were then specified separately, which is the part that only becomes possible once the hardware is not yours. Development and QA now run to a schedule and stop outside working hours.

The landing zone

• Multi-AZ VPC, with the SAP database and application tiers in separate Availability Zones.
• The SAP Oracle database self-managed on Amazon EC2. SAP supports Business Suite databases on EC2 rather than on RDS, so that is where it went. Amazon RDS for Oracle runs the group’s adjacent, non-SAP databases, where a managed service is permitted and takes administration off the team.
• Amazon EBS split by role, with IOPS and throughput provisioned separately from capacity. This is usually why SAP runs faster after a migration than it did on the array it left.
• Backups to Amazon S3 with versioning and lifecycle rules, held in a different region from the running landscape.
• Every system registered with AWS Systems Manager for SAP, so start, stop and patching are application-aware.

Moving six terabytes without a maintenance window

The database was the constraint. Six terabytes carrying twenty years of history will not move inside any window a distribution business can offer.

So it was not moved inside one. The target was seeded from a backup and restored without affecting production. From that point change data capture carried every new transaction across, continuously. The distance between the two systems stopped being a quantity of data waiting to be copied and became a number on a dashboard: replication lag, measured in seconds.

The two ran alongside each other while that number was watched, the interfaces were exercised against the target, and the finance and merchandising teams checked their own data. That went on for weeks rather than hours. Nothing about it needed to be rushed.

Choosing the moment to switch

The cutover was planned, not improvised. By the time it was scheduled, replication lag had been sitting at zero for days, so the remaining question was not whether the data was ready but when the switch would cost the business least.

We took the window from the group’s own activity data: the quietest point in the week for concurrent users, clear of dispatch cut-offs and outside the production shift. Users were locked out, the final transactions confirmed applied, the application repointed and restarted.

Six minutes, start to finish. There was nothing to restore, nothing to import and no reconciliation backlog waiting on the other side, because the data was already there. The runbook had been rehearsed against copies of production and it behaved the way the rehearsals had.

Business downtime was none. No trading hour was lost, no retail chain missed a file, and the production schedule was not moved. The source system stayed up and untouched through the agreed rollback window, and was decommissioned once nobody wanted it any more.

Sixty chains, seventy interfaces

Interfaces break distribution migrations more often than databases do. Every retail chain has its own file format, its own schedule and its own tolerance for something arriving late, and there were around seventy of these flows.

Each one was inventoried, repointed and tested against the target using real message traffic rather than a connectivity check. Because the target had been live as a DR site for months, that work spread across weeks of normal working hours instead of being crammed into a cutover.

Recovery, tested rather than assumed

Backups existed before this project. Evidence that a recovery would work did not, and the recovery copy lived in the same place as the primary.

Both changed. Backup is now cross-region; the RTO and RPO were agreed with the business rather than inherited from a contract; and a full restore was run end to end and timed at four hours against a 15-minute RPO. The previous position was three days, and it was a document rather than a measurement.

Running it, and handing compute back

After go-live the landscape moved onto managed support: monitoring at the SAP layer rather than only at the instance layer, and patching windows agreed against both the distribution and production calendars.

Thirty days in we re-sized against measured production behaviour instead of the pre-migration estimate, and handed back around 20% of the compute specified at go-live. Non-production stops outside working hours. Between them, those two habits account for most of the gap between a migration that reduces cost and one that simply relocates it.

Business impact

• 31% lower infrastructure run-rate than the on-premises equivalent, counting hardware amortisation, hosting, power and maintenance, and measured after the thirty-day right-sizing pass.
• 58% lower non-production cost, from stopping development and QA outside working hours. That saving is not available on hardware the group has already bought.
• The refresh decision is gone. A single large capital commitment covering the whole ERP estate is no longer on the table.
• Capacity changes take under an hour instead of a procurement cycle. Adding a brand, a category or a country is no longer a twelve-month forecasting exercise.
• Zero business downtime at cutover, with the application quiesced for six minutes at the quietest point in the week.
• Zero unplanned outages since go-live, at 99.95% measured availability across every market the group serves.
• Disaster recovery from three days on paper to four hours executed, cross-region, with a 15-minute RPO, and without buying a second landscape to get it.
• 38% shorter nightly batch window, from provisioning EBS IOPS and throughput independently of capacity.
• No ABAP changes and no retraining. Same system, same processes, same screens, which is why adoption never became a workstream.

What comes next

With the estate on AWS, the decisions in front of the group are commercial rather than structural: S/4HANA on a timetable that suits the business, analytics across twenty years of sell-in data and 10,000 SKUs, closer integration with the chains it supplies. None of them now begins with a conversation about whether the infrastructure can take it.