SAP Upgrade & Migration Services
SAP Upgrade and Migration Services cover two related but distinct activities — upgrading your SAP software to a newer version and migrating your SAP landscape to a new database, operating system, infrastructure or deployment model. Both introduce risk that requires structured methodology, technical depth and experience to manage. 2iSolutions delivers both as a SAP Gold Partner, with ECC-to-S/4HANA conversion, database migration, cloud migration and Business One version upgrades all within our practice.
Upgrade vs migration — understanding what each involves
The terms are often used interchangeably but describe different technical activities with different risks, timelines and methodologies. Many projects involve both simultaneously — an ECC-to-S/4HANA conversion that also moves to cloud is both an upgrade and a migration.
SAP Upgrades
Moving the SAP application software to a newer release — upgrading the functional scope, technical platform and underlying ABAP stack. Upgrades bring new features, performance improvements and continued SAP maintenance. The primary upgrade in most landscapes today is ECC to S/4HANA.
- SAP ECC 6.0 to SAP S/4HANA (conversion)
- SAP S/4HANA version upgrade (e.g. 1909 → 2022 → 2023)
- SAP Business One version upgrade
- Support package stack (SPS) upgrade — within a release
- SAP kernel upgrade — without application change
- SAP BTP and cloud service version updates
SAP Migrations
Moving the SAP system to a different database, operating system, infrastructure or deployment model — without necessarily changing the SAP application version. Migrations change how SAP runs rather than what SAP does. They often happen alongside upgrades but can also be executed independently.
- Database migration: any DB → SAP HANA (DMO)
- OS/DB migration: Unix/AnyDB → Linux/HANA
- Suite on HANA migration (R/3 or ECC to HANA DB)
- On-premise → cloud (hyperscaler or RISE)
- System consolidation: multiple landscapes → one
- System copy and landscape refresh
The most common combination: ECC to S/4HANA conversion using SUM DMO (Software Update Manager with Database Migration Option) — a single technical activity that simultaneously upgrades ECC to S/4HANA and migrates the database from Oracle/DB2/SQL Server to SAP HANA. Understanding that this is one combined activity with specific technical dependencies helps set realistic expectations for timeline and testing scope.
SAP upgrade services — what we deliver
ECC to S/4HANA Conversion
The central upgrade challenge for most SAP landscapes — converting SAP ECC to S/4HANA using SAP's Software Update Manager (SUM) with Database Migration Option (DMO). Covers custom code adaptation, simplification list remediation, functional delta review and cutover management. Available as brownfield (system conversion) or selective data transition depending on client requirements.
S/4HANA Version Upgrades
Moving S/4HANA between major releases — from 1709, 1809 or 1909 to 2020, 2021, 2022 or 2023. Each major version brings new functionality, changed APIs and deprecated features that affect custom code. We execute the technical upgrade, identify breaking changes in custom ABAP, adapt the code and validate the functional delta before moving to production.
SAP Business One Version Upgrade
Business One version upgrades from 9.x or 10.x to the current release — testing add-ons, SDK-based extensions and customisations before production upgrade. Covering the version pre-check, add-on compatibility validation, upgrade execution and regression testing to ensure the system functions identically at the new version.
Support Package Stack Upgrades
Applying SAP support package stacks (SPS) to keep the system current on security patches, corrections and minor improvements — without a major version upgrade. SPS upgrades require impact analysis, regression testing on critical processes and controlled transport to production. We manage the entire SPS cycle under AMS for ongoing clients.
Custom Code Adaptation
During any SAP upgrade, custom ABAP code must be reviewed against the new ABAP API and SAP object landscape. Removed function modules, changed database tables, new syntax requirements and deprecated APIs all create compilation errors that block the upgrade. We use SAP's ABAP Test Cockpit and Custom Code Migration Cockpit to systematically identify and remediate breaking changes.
Upgrade Assessment & Readiness
Before any upgrade, a structured readiness assessment — SAP Readiness Check output analysis, custom code volume and complexity assessment, functional delta between current and target release, data volume analysis for downtime estimation and a risk-stratified upgrade plan with realistic timeline and testing scope. Prevents scope surprises after the upgrade project has started.
SAP migration types — database, OS, cloud and system consolidation
Migrations address infrastructure and platform changes rather than application version changes. Each migration type has distinct technical requirements, toolsets and risk profiles.
Database Migration to SAP HANA
Migrating the SAP database from Oracle, DB2, Microsoft SQL Server or MaxDB to SAP HANA — the prerequisite for both S/4HANA and advanced analytics on live data. Executed using SUM DMO combined with the ECC-to-S/4HANA upgrade, or independently as a Suite on HANA migration.
- SUM DMO — combined upgrade + DB migration
- SAP HANA migration guide for target release
- Data volume management before migration
- Post-migration performance tuning
- Lava International: Suite on HANA in 50 days, 2–3× performance
OS Migration (Any OS → Linux)
Moving the SAP system from a Unix platform (IBM AIX, HP-UX, Oracle Solaris) to Linux — required for S/4HANA (Linux is the supported OS), for hyperscaler cloud hosting and for access to Linux-native hardware efficiency. Often executed alongside the HANA migration using SUM DMO or heterogeneous system copy.
- Heterogeneous system copy methodology
- SUM DMO for combined OS + DB migration
- Linux sizing and hardware provisioning
- Transport landscape rebuild on new OS
- Interface and integration re-testing
On-Premise to Cloud Migration
Moving the SAP landscape from an on-premise data centre to hyperscaler cloud (AWS, Azure, GCP) or to RISE with SAP managed infrastructure. Infrastructure migration that retains the same application landscape — changing who manages the servers and Basis, not changing what the SAP system does.
- Hyperscaler sizing and architecture
- SAP HANA on IaaS configuration
- Network and connectivity setup
- Backup and DR on cloud
- Cutover from on-premise to cloud
System Copy & Landscape Refresh
Homogeneous or heterogeneous system copies — refreshing the QA or development system from production, creating sandbox environments, setting up new landscape tiers. Used for project environments, upgrade test systems and as a first step in cloud migrations.
- Homogeneous copy — same OS/DB
- Heterogeneous copy — different OS or DB
- Client copy within existing landscape
- Transport landscape reconfiguration
- Post-copy system configuration
System Landscape Consolidation
Merging multiple SAP systems into one — common after acquisitions, for organisations running separate S/4HANA instances per division, or for companies that have accumulated separate SAP landscapes over time. Requires Selective Data Transition (Bluefield) tooling from SAP or third-party specialist tools.
- Company code merger and data harmonisation
- SAP Landscape Transformation (SLT) toolset
- Chart of accounts and master data alignment
- Historical data migration and cutover
- Integration landscape simplification
Data Migration (Implementation Context)
Migrating master data and transactional data from a legacy system into a new SAP implementation — customer, vendor and material masters, opening financial balances, inventory stock, open orders and historical records. Distinct from system migration; uses SAP's Data Migration Cockpit, LSMW and custom ABAP migration programmes.
- Legacy data extraction and cleansing
- SAP Data Migration Cockpit
- Migration object modelling and mapping
- Mock migration runs in QA environment
- Final load validation and sign-off
Six-phase upgrade & migration methodology — from assessment to go-live
Every upgrade or migration follows a structured methodology — the phases are standard; the content of each phase is calibrated to the specific upgrade or migration type.
Assessment
Readiness check, custom code analysis, functional delta, data volume, downtime modelling
Planning
Upgrade strategy, approach selection, timeline, testing plan, cutover runbook, team mobilisation
Preparation
System prerequisites, custom code adaptation, pre-upgrade checks, test environment setup
Testing
Functional regression, integration testing, performance benchmarking, UAT, defect resolution
Cutover
Dress rehearsal, go/no-go criteria, production execution, fallback plan on standby
Stabilisation
Hypercare, issue resolution, performance monitoring, knowledge transfer, AMS handover
The risks we mitigate — in every upgrade and migration
Most upgrade and migration failures are predictable and preventable. These are the risks our methodology is specifically designed to address.
Custom Code Failures at Go-Live
Incomplete custom code analysis leaves ABAP programmes that fail on the new release. We run the full SAP Custom Code Migration Cockpit scan — not a sampling — and adapt every programme that breaks before the production upgrade runs.
Extended Downtime at Cutover
SUM DMO runtime is proportional to data volume. We run mandatory dress rehearsals on a production-equivalent system — with actual production data volumes — so the cutover window is known before the production window is scheduled, not discovered during it.
Interface Failures Post-Migration
System migrations change IP addresses, hostnames, RFC destinations and interface parameters. Every integration point is documented, tested in the migrated environment and validated before production cutover — not discovered by the business the morning after go-live.
Performance Degradation After Upgrade
New releases change query execution plans, buffer configurations and memory requirements. We run performance benchmarks on the upgraded test system against production baselines — identifying regressions before they reach users, not after the business reports slowdowns.
No Fallback Plan
Every cutover execution has a defined fallback decision point and a documented rollback procedure. The fallback plan is rehearsed in the dress rehearsal, not written during a failed cutover under pressure at 3am.
Simplification List Non-Compliance
S/4HANA removes or restructures data models that ECC relied on — materials management tables, FI document structures, logistics information system. Simplification list items not addressed before conversion cause data inconsistencies. We validate every applicable item against your active transaction data.
SAP migration in practice — Lava International
What makes our upgrade and migration practice different
Dress Rehearsal — Non-Negotiable
We do not execute a production cutover without at least one full dress rehearsal on a production-equivalent system with actual production data volumes. This is not a best practice we recommend — it is a delivery standard we enforce. The dress rehearsal is where cutover timeline surprises are discovered; not during the production window.
21 Years of SAP Technical Depth
We have been implementing and managing SAP since 2005 — through R/3, ECC 6.0, EHP stacks, Suite on HANA, and now S/4HANA 2023. Our technical consultants have executed upgrades across multiple SAP releases and understand how each release changes the upgrade execution, custom code requirements and post-upgrade stabilisation profile. This is institutional depth, not project experience.
Full Custom Code Scan — Not Sampling
Our custom code analysis covers every custom ABAP object in your repository — not a statistical sample. We use SAP's Custom Code Migration Cockpit and ABAP Test Cockpit to identify every compilation error, every usage of deprecated APIs and every access to removed database tables. Incomplete scanning is the single most common cause of upgrade project overruns.
Post-Migration AMS Continuity
The team that migrates the system continues as AMS partner — knowing exactly what changed, what was adapted and what edge cases surfaced during migration testing. Lava International's 30% cost reduction came from this continuity. Handing to a different AMS partner after migration loses the context that makes co-innovation possible.
SUM DMO Execution Experience
SAP's Software Update Manager with Database Migration Option (SUM DMO) is the standard toolset for ECC-to-S/4HANA with HANA migration. It is a technically complex tool that behaves differently depending on database vendor, data volumes, custom code load and OS configuration. Our execution experience across multiple SUM DMO runs prevents the common first-time-runner mistakes that extend timelines.
SAP Gold Partner — Direct Escalation
When SUM DMO encounters an undocumented error — and it sometimes does — direct SAP partner escalation matters. Gold Partnership provides a faster SAP support path than standard customer escalation, access to undocumented SAP Notes and a technical advisor relationship with SAP that resolves blockers faster than a customer support message.
SAP upgrade and migration delivery from a Gold Partner with 21 years of technical SAP experience
Our upgrade and migration practice is built on institutional technical depth — not a team assembled for a project. The same consultants who executed Lava International's 50-day HANA migration manage the ongoing AMS engagement and have delivered S/4HANA implementations across manufacturing, FMCG, high tech and real estate.
SAP upgrade & migration: frequently asked questions
What is the difference between an SAP upgrade and an SAP migration?
An upgrade changes the SAP application software to a newer release — adding features, changing APIs and updating the ABAP stack. A migration changes the infrastructure the SAP system runs on — the database, operating system, or hosting environment — without necessarily changing the SAP application version. The ECC-to-S/4HANA conversion is both simultaneously: it upgrades the application from ECC to S/4HANA and migrates the database from AnyDB to HANA, typically in a single SUM DMO execution.
How long does an ECC to S/4HANA conversion take?
The technical conversion (SUM DMO execution) takes hours to days depending on data volumes — typically 1–3 days for the actual conversion run including downtime. The project to prepare for, execute and stabilise the conversion takes 4–12 months depending on custom code complexity, data volumes and functional delta scope. A business with moderate ECC customisation and a focused scope can go from project kick-off to production conversion in 4–6 months; a heavily customised ECC with large data volumes takes longer.
What is a Suite on HANA migration and how is it different from S/4HANA?
Suite on HANA is SAP ECC or R/3 running on the SAP HANA database instead of Oracle, DB2 or SQL Server — without upgrading the application to S/4HANA. It gives HANA's performance benefits (in-memory processing, faster analytics, real-time reporting) while retaining the ECC application landscape. It's a stepping stone — not a destination — since S/4HANA's 2027 deadline still requires a full conversion. Lava International's 50-day migration was a Suite on HANA migration; the HANA platform then enables the S/4HANA conversion with a shorter downtime window.
What is brownfield vs greenfield in the context of ECC to S/4HANA?
Brownfield (system conversion) converts the existing ECC database to S/4HANA in place — all historical data, configuration and custom code migrated. Lower go-live risk but inherits ECC technical debt. Greenfield is a fresh S/4HANA implementation — built on SAP Best Practices without ECC's customisations, with data migrated selectively. Brownfield is faster; greenfield is cleaner. The choice depends on how much ECC customisation is worth preserving versus redesigning. Selective data transition (Bluefield) is a hybrid — specific entities or company codes migrated with selective historical data.
How is production downtime minimised in an ECC to S/4HANA migration?
SUM DMO operates in phases — most of the processing runs while the system is still live (online phase), with only the final cutover steps requiring downtime. The downtime window is driven by data volume and hardware speed. We reduce it through: data archiving and deletion before the upgrade (reducing what needs to be processed), hardware sizing for the migration server (more CPUs and RAM), a practice run on a production-equivalent system to measure actual runtime, and a precisely planned cutover checklist that eliminates improvisation during the window.
What happens to custom ABAP code in an upgrade?
Every SAP upgrade changes or removes APIs, database tables and syntax that custom ABAP may depend on. In an ECC-to-S/4HANA conversion, common breaking changes include: removed LIS tables (replaced by S/4HANA structures), changed MARA/MARC table fields, removed function modules in logistics, BAPI signature changes and syntax not supported in the new ABAP release. We run SAP's Custom Code Migration Cockpit to identify every affected object, prioritise by business criticality and adapt the code before the production conversion. "Adapt and upgrade" — not "upgrade and fix later."
Planning an ECC to S/4HANA conversion, HANA migration or SAP version upgrade?
A structured upgrade readiness assessment — covering custom code volume, data volumes, downtime modelling and a realistic timeline — is the right starting point before committing to a project scope. It takes 2–3 weeks and prevents the most common causes of upgrade project overruns.