"Lift and shift" is one of the most overused phrases in enterprise software, and one of the least understood when it comes to SAP MII. For some vendors it means literally copying NetWeaver containers to a cloud VM. For others it means a wholesale clean-core rewrite dressed up as preservation. Neither captures what actually happens when a real SAP MII estate moves to a modern platform without rebuilding from scratch. This page explains exactly what lift and shift means in the SAP xMII context, how the mechanics work end-to-end, what gets carried forward intact, and how iFactory AI executes the approach in practice. No hand-waving. No marketing abstractions. Just the architecture, the workflow, and the engineering. Book a 30-minute working session to walk through the lift-and-shift approach against your specific MII landscape.
1:1
Behavioural mapping between MII artifacts and modern platform equivalents
3
Layers of preservation — logic, integrations, and operator UI
8–14
Months for typical multi-site lift-and-shift vs. 18–36 for clean-core rebuild
0
Custom MII business rules redesigned from a blank page
What "Lift and Shift" Actually Means for SAP MII
The phrase carries different meanings depending on who is using it. To set a clear baseline before we walk through the mechanics, here are the three most common definitions in market — and which one we are actually talking about when we say lift and shift for SAP xMII.
DEFINITION 01
Infrastructure Lift-and-Shift
Move the existing NetWeaver server to a cloud VM (Azure, AWS, GCP). The MII application runs unchanged, but in a new hosting location.
Verdict: Buys time but solves nothing. The platform is still EOL. Patches still stop in 2030. Not a real modernization path.
DEFINITION 02
Clean-Core Rewrite Disguised as Lift
Inventory MII artifacts, then rebuild every BLS transaction, query, and dashboard from scratch on the target platform's APIs. Marketing calls this "lift" but engineering calls it ground-up redevelopment.
Verdict: Honest rebuild, not lift-and-shift. Forces 18–36 month timelines and full revalidation cycles.
DEFINITION 03
Behavioural Lift-and-Shift (iFactory)
Extract logic, workflows, integrations, and UI patterns from MII. Translate them onto a modern runtime that produces identical outputs for identical inputs. Validate behavioural equivalence before any cutover.
Verdict: Real preservation of accumulated value, modern runtime, predictable timeline. The approach this page documents.
The Three Layers of Preservation
An SAP MII application is never just "one thing." It is at least three layers stacked on top of each other — business logic, integrations, and operator UI. Lift and shift only works when all three layers are preserved together. Below is what lives in each layer and what gets carried forward.
L1
Business Logic Layer
The decision rules, workflows, calculations, and exception handling encoded in BLS transactions, custom action blocks, and scripted logic. This is where the actual value of your MII investment lives.
What's there: BLS transactions, action blocks, custom Java/JS, scheduled jobs, scripted calculations
What's preserved: Decision flow, branching logic, error handling, edge-case rules, output formats
How it's translated: BLS becomes configurable workflow definitions; custom code becomes containerized services invoked via API
L2
Integration Layer
The connections between MII and the rest of your environment — SAP ECC or S/4HANA, PLCs, historians, SCADA systems, identity providers, third-party services. The plumbing that keeps data flowing.
What's there: Data servers, PCo connections, RFC/BAPI calls, IDoc handlers, OData services, JDBC links
What's preserved: Endpoint definitions, sample rates, tag mappings, authentication patterns, transaction semantics
How it's translated: Data servers become native edge gateway connectors; ERP integrations move to OData/RFC adapters; identity moves to modern SSO
L3
Operator UI Layer
The dashboards, screens, alerts, and workflows operators actually use every shift. The accumulated UX conventions your shift leads have learned to trust over years.
What's there: SSCE pages, KPI dashboards, OEE displays, downtime entry screens, alert configurations
What's preserved: Layout grammar, tab order, colour codes, KPI definitions, filter conventions, alert thresholds
How it's translated: SSCE pages map to modern responsive dashboards that mirror the original visual conventions; mobile-first variants are added without changing the desktop experience
Three Layers, One Coherent Migration. Skip Any One and the Others Break.
Most failed migrations preserve only the logic layer and force operators onto an unfamiliar UI, or move the integrations without bringing the calculations along. iFactory's lift-and-shift methodology handles all three layers as a single program — because real-world MII applications only work when all three are coordinated.
How It Works: The End-to-End Mechanics
Now the mechanics. This is what actually happens when an SAP MII estate moves through the lift-and-shift process — from the moment scanners first connect to your MII server, to the moment the legacy system is formally decommissioned. Five steps, executed in order.
STEP 1
Automated Discovery & Cataloguing
Connect read-only scanners to your live SAP MII server. Walk every BLS transaction, xMII query, SSCE page, action block, scheduled job, and configuration object. Generate a structured catalog with metadata: dependency graph, last-execution timestamp, current usage frequency, owning user, and integration touchpoints.
Produces: Annotated artifact inventory tagged for preserve, transform, or retire
STEP 2
Pattern Mapping & Translation
Translate each MII artifact into its iFactory equivalent using a deterministic pattern library. BLS transactions become configurable workflows. xMII queries become typed data connector definitions. SSCE pages become modern dashboards that preserve the original layout grammar. Custom Java action blocks become containerized services. Every translation rule is documented and reviewable.
Produces: Translated artifacts deployed to target platform; translation log per artifact
STEP 3
Parallel-Run Behavioural Equivalence
Run the original MII artifact and the translated equivalent against the same input data, in parallel, for weeks. Compare outputs row-by-row, KPI-by-KPI, alert-by-alert. Flag any discrepancies. Iterate translation rules until equivalence is proven across the full input range. This step is what makes lift-and-shift safe — nothing reaches production without producing the same answer MII does.
Produces: Equivalence validation report with pass/fail per artifact; sign-off from operations and audit
STEP 4
Site-by-Site Cutover with Hypercare
Cut over one site at a time. Never all sites at once. Run new and old in parallel for at least one full production cycle per site. Hypercare for 30–60 days with elevated support coverage. Lessons learned from the first site feed the playbook for subsequent sites. This wave-based approach is the difference between a smooth migration and a panicked rollback.
Produces: Per-site go-live confirmation; hypercare incident log; rollback plan if needed
STEP 5
Decommissioning & Posture Refresh
Once every site has run cleanly on the new platform for one full quarter, formally retire MII components. Archive historical data for compliance lookups. Update audit documentation. Refresh cyber insurance to reflect the modernized posture. The migration is not "done" until the legacy system is officially out of the supported landscape.
Produces: MII decommissioning certificate; updated audit and insurance documentation
The Behavioural Equivalence Test: How We Prove It Works
The single hardest engineering problem in any lift-and-shift program is proving the new platform produces the same answers as the old one — for every input, every edge case, every reporting period. Below is exactly how we run that proof, and why it is the linchpin of the whole methodology.
Input Capture
Capture real production input data flowing into MII — sensor readings, ERP transactions, operator entries, scheduled triggers — for a representative sample window (typically 4–6 weeks).
Twin Execution
Replay the captured input against both the original MII artifact and the translated iFactory equivalent. Both run with identical timestamps, identical data, identical context.
Output Diff
Compare every output side by side — calculated values, status changes, alerts fired, work orders created, KPIs updated. Tolerance bands are defined per artifact (some calculations require exact match, others permit small floating-point variance).
Discrepancy Triage
Every difference is investigated. Most are translation-rule refinements. Some are bugs in MII the team never noticed. Each discrepancy gets a disposition: fix on new platform, accept tolerance, document deviation.
Sign-Off
Operations, quality, and audit stakeholders formally sign off on equivalence per artifact. The artifact is then cleared for production cutover. Nothing reaches production without sign-off.
What Lift-and-Shift Is — and What It Is Not
The boundaries matter. Below is a clear statement of what lift-and-shift includes, and where it ends. Setting these expectations early prevents the most common scope-creep failures in MII migrations.
WHAT IT IS
A disciplined preservation of business logic, integrations, and UI patterns from MII onto a modern platform
Behavioural equivalence — same input, same output, validated before cutover
A pathway to modernization that protects accumulated investment
A wave-based, site-by-site rollout with hypercare per site
Compatible with later modernization layers — AI, edge processing, mobile UX
WHAT IT IS NOT
A literal copy of NetWeaver containers to a cloud VM
A clean-core rewrite disguised as preservation
An excuse to skip operator training or change management
A way to avoid retiring genuinely obsolete artifacts
A guarantee of zero refactoring — some platform-specific calls always need adjustment
Lift-and-Shift Done Honestly Beats Rebuild Done Quickly. Every Time.
The methodology described on this page is what iFactory has refined across SAP MII migrations in automotive, pharma, food, and process industries. It is rigorous, documented, and repeatable — and it consistently delivers production-ready outcomes in a fraction of the time clean-core rebuilds require.
The Tooling Behind the Methodology
Lift-and-shift at scale requires real engineering tooling — not consultants with spreadsheets. Below are the four core capabilities that make the iFactory lift-and-shift methodology work in practice.
01
MII Artifact Scanner
Read-only connector to live MII servers. Walks every transaction, query, page, action block, and configuration object. Builds a structured catalog with full dependency graph and metadata. Runs without taking MII offline.
02
Pattern Translation Library
Deterministic translation rules from MII concepts to iFactory equivalents. Every BLS pattern has a documented mapping. Custom logic outside standard patterns gets flagged for human review and bespoke handling.
03
Behavioural Equivalence Harness
Capture-and-replay framework that drives both MII and the translated equivalent with identical inputs. Diffs outputs at the field, KPI, and alert level. Generates equivalence reports per artifact with pass/fail and tolerance analysis.
04
Site Cutover Runbook
Pre-built, customizable runbook for site-by-site cutover including parallel-run procedures, hypercare protocols, rollback triggers, and post-cutover validation checklists. Refined across multiple production migrations.
Frequently Asked Questions
Is iFactory lift-and-shift the same as moving MII to a cloud VM?
No. Moving MII to a cloud VM is infrastructure lift-and-shift — the application is unchanged but hosted differently. iFactory's behavioural lift-and-shift translates MII artifacts onto a modern, supported platform that produces identical outputs. Different problem, different solution. Book a Demo for a side-by-side comparison.
How does the behavioural equivalence test handle randomness or time-dependent logic?
Time-dependent logic is replayed with identical timestamps in both systems. Random or stochastic logic gets seeded so both runs produce the same sequence. Tolerance bands are defined per artifact — some require exact match, others accept small variances for floating-point or rounding behaviour. Every tolerance is documented and reviewed. Talk to Support for the full validation methodology.
Can lift-and-shift handle MII artifacts that depend on retired equipment or obsolete processes?
Those get tagged "retire" during Step 1 cataloguing — and they should not be carried forward. Lift-and-shift preserves what is still in active use; the housekeeping pass during cataloguing is the right time to clean up genuinely obsolete artifacts. Book a Demo to see disposition tagging in practice.
What if some MII customizations cannot be cleanly translated?
Outliers are flagged during Step 2 and handled bespoke — typically as containerized services that the iFactory platform invokes via API. The pattern library covers the vast majority of MII customizations; the residual percentage gets case-by-case engineering attention. Nothing gets silently dropped. Talk to Support for outlier-handling examples.
How is this different from migrating to SAP DM Cloud?
SAP DM follows a clean-core architecture — direct database access is gone, custom logic must be redesigned via APIs and the POD designer. There is no automatic translation path. iFactory's lift-and-shift preserves MII logic patterns through deterministic translation onto a modern runtime. Different philosophies, different timelines, different risk profiles. Book a Demo for a comparison.
Can we add modernization on top of lift-and-shift later?
Yes — and many customers do. Lift-and-shift gets you to a modern, supported platform with logic intact. Modernization layers — AI copilots, predictive maintenance, vision QC, mobile-first UX, edge processing — are added as separate workstreams once the lift-and-shift baseline is stable. The two are sequential, not exclusive. Talk to Support about phased modernization patterns.
Lift-and-Shift, Done Right. Same Behaviour, Modern Platform, Predictable Timeline.
No infrastructure-only shortcuts. No clean-core rewrites in disguise. Just disciplined preservation of the business logic, integrations, and UI patterns your operators trust — translated onto a modern, AI-ready runtime with behavioural equivalence proven before any cutover.
3 layers preserved: logic, integrations, UI
Behavioural-equivalence validation before any cutover
8–14 month timelines vs. 18–36 for rebuild
Site-by-site rollout with per-site hypercare
AI & modernization layered on top once baseline is stable
