SAP S/4HANA-migrering i komplexa systemlandskap: så fungerar en Migration Factory

Att migrera dussintals SAP-system behöver inte ta flera år. Läs mer om hur SAP Migration Factory-metoden hjälper till att strukturera och påskynda storskaliga S/4HANA-migrationer.

För stora företag handlar en övergång till SAP S/4HANA sällan om att migrera ett enda ERP-system.

SAP-landskap utvecklas över tid i takt med verksamheten. Nya dotterbolag, förvärv, lokala konfigurationer och verksamhetsspecifika integrationer kan leda till att företag får flera SAP-system som spänner över länder, produktionsanläggningar, gränssnitt och många års kundanpassad utveckling.

Denna internationella struktur är vanlig i Sverige, där många större koncerner är verksamma på flera marknader och genom flera juridiska enheter. Enligt Tillväxtanalys hade 4 244 svenska koncerner dotterbolag utomlands 2023. För organisationer som använder SAP kan sådana strukturer innebära systemlandskap där centrala koncernfunktioner behöver samverka med lokala processer, regulatoriska krav och operativa system i olika affärsenheter och på olika marknader.

Planeringen behöver därför omfatta beroenden mellan systemen, i vilken ordning de kan migreras och vilken påverkan varje migreringsvåg kan få på verksamheten. Den återstående underhållsperioden för SAP Business Suite 7 innebär dessutom en tydlig tidsmässig faktor. Ordinarie underhåll för centrala SAP Business Suite 7-applikationer pågår till slutet av 2027, följt av möjlighet till utökat underhåll till slutet av 2030 samt ytterligare övergångsalternativ för vissa särskilt komplexa kundmiljöer. För företag som hanterar flera ECC-system är en samordnad migreringsplanering avgörande för att kunna flytta flera system till SAP S/4HANA utan onödiga störningar i affärskritisk verksamhet.

Det är i detta sammanhang som en SAP Migration Factory blir relevant.

Vad är en SAP Migration Factory?

En SAP Migration Factory är en standardiserad leveransmodell för att genomföra flera SAP-migreringar med gemensamma processer, styrning, verktyg, roller och kvalitetskontroller.

I stället för att hantera varje SAP S/4HANA-migrering som ett separat projekt etablerar fabriksmodellen ett gemensamt ramverk som kan återanvändas för olika system och migreringsvågor.

En typisk livscykel omfattar:

• Analys

• Förberedelser

• Migrering

• Validering

• Stabilisering

De exakta aktiviteterna beror på system, dataomfattning och vald migreringsstrategi. Målet är att standardisera återkommande arbete och samtidigt låta relevanta specialister hantera systemspecifika frågor.

Utan en sådan modell kan varje system kräva en egen readiness-analys, konfiguration av verktyg, processer för datavalidering, testscenarier, cutover-planering och stabiliseringsmodell. I ett omfattande systemlandskap leder denna upprepning till högre kostnader, större samordningsbehov och mindre förutsägbar leveranskvalitet.

En Migration Factory minskar variationen genom att återanvända metoder, mallar, automation och styrningsmodeller mellan migreringsvågorna.

När är en Migration Factory relevant?

En Migration Factory kan vara relevant när:

• flera SAP-system eller juridiska enheter ska migreras inom samma transformationsprogram;

• flera migreringsvågor kan återanvända liknande aktiviteter för readiness, testning och cutover;

• produktionsanläggningar eller dotterbolag har omfattande lokala avvikelser;

• flera olika migreringsstrategier behöver användas inom samma program;

• beroenden mellan ERP, MES, WMS, logistik, ekonomi och externa gränssnitt gör det svårt att styra projekten separat.

För ett relativt enkelt ERP-landskap kan ett traditionellt migreringsprojekt vara tillräckligt. Affärsnyttan med en Migration Factory ökar i takt med antalet system, beroenden, länder och migreringsvågor.

Varför är SAP-landskap med flera anläggningar och länder svåra att migrera?

En svensk industrikoncern kan exempelvis kombinera omfattande tillverkningsverksamhet i Sverige med produktionsanläggningar, distributionsnätverk och försäljningsorganisationer i Norden, övriga Europa och andra delar av världen.

ERP-konfigurationer kan skilja sig mellan olika anläggningar, samtidigt som förvärvade verksamheter ofta behåller befintliga SAP-system. SAP är dessutom vanligtvis integrerat med produktionssystem, lagerhanteringslösningar, transportlösningar, bankgränssnitt, analysmiljöer, leverantörer och lokalt utvecklade applikationer.

När dessa system ingår i samma operativa flöde kan en migreringsvåg påverka produktion, logistik, rapportering, betalningsflöden och lokalt hanterade processer i flera jurisdiktioner.

Programmet behöver därför besvara mer än den tekniska frågan om hur SAP ECC konverteras till SAP S/4HANA. Det behöver också fastställa:

• vilka system som ska konverteras, konsolideras, ersättas eller avvecklas;

• vilka processer som bör förbli lokala och vilka som bör standardiseras;

• i vilken ordning migreringsvågorna ska genomföras;

• hur beroenden inom data och integrationer ska hanteras;

• hur affärskritisk verksamhet ska skyddas under cutover.

För digitalt mogna organisationer är dessa beslut också nära kopplade till målarkitekturen. En migrering är ofta ett tillfälle att förenkla den befintliga systemmiljön, förbättra integrationen mellan systemen och definiera hur SAP ska fungera inom ett bredare moln- och applikationslandskap.

Molnanvändningen är redan utbredd i Sverige. Enligt Eurostat använde 72 % av svenska företag med minst tio anställda betalda molntjänster 2025. Fokus ligger därför i allt högre grad på hur molnmiljöer utformas och förvaltas – bland annat när det gäller arkitektur, interoperabilitet, säkerhet, styrning och konkret verksamhetsnytta.

Exempel: en svensk koncern med verksamhet i flera länder

Anta att en tillverkningskoncern med huvudkontor i Sverige har produktionsanläggningar i Sverige, Polen och Tyskland.

Koncernen använder två SAP ECC-miljöer parallellt med ett SAP S/4HANA-system som följt med genom ett företagsförvärv. De enskilda anläggningarna kan samtidigt ha egna integrationer mot MES- och lagersystem, medan ekonomi och rapportering delvis är centraliserade.

En Migration Factory kan inledas med en gemensam analys av samtliga tre miljöer. En enhet med lägre riskprofil kan ingå i den första migreringsvågen, så att programmet kan validera readiness-kontroller, testscenarier, cutover-processer och styrningsmodellen.

Erfarenheterna från den första vågen kan därefter återanvändas för större anläggningar, medan lokala MES-, WMS- och regulatoriska integrationer hanteras som systemspecifika aktiviteter.

Vad standardiserar en SAP Migration Factory?

En Migration Factory kombinerar centralt standardiserade funktioner och arbetssätt med systemspecifikt genomförande i respektive migreringsvåg.

Systemberedskap, kundanpassad kod och clean core

Förberedelserna inför migreringen börjar med att skapa en tydlig bild av vad som faktiskt finns i det befintliga systemlandskapet.

SAP Readiness Check hjälper till att identifiera simplification items, behov kopplade till kundanpassad kod och andra förutsättningar inför övergången till SAP S/4HANA.

Maintenance Planner stödjer den tekniska planeringen genom att kontrollera systemkomponenter, add-ons och beroenden.

Kundanpassad kod kräver särskild uppmärksamhet i SAP-miljöer som utvecklats under lång tid. ABAP Test Cockpit hjälper till att identifiera kundanpassad kod som behöver anpassas för SAP S/4HANA. Analys av användning och omfattning kan därefter hjälpa teamen att avgöra vilka utvecklingar som fortfarande behövs och vilka som kan avvecklas.

Analysen stödjer även en clean core-strategi, en viktig princip inom RISE with SAP. Genom att tillämpa clean core-principer kan organisationen avgöra vilka kundanpassningar som bör behållas, vilka som kan ersättas med standardfunktionalitet i SAP och vilka som bör byggas om med moderna alternativ för utbyggbarhet.

Datamigrering, integrationer och testning

Äldre ERP-system innehåller ofta duplicerade, ofullständiga, inkonsekventa eller inaktuella data. Att flytta all information utan att först fastställa vad som faktiskt behöver bevaras riskerar att föra över onödig komplexitet till SAP S/4HANA.

För initial dataladdning och nyimplementeringar som stöds av lösningen kan SAP S/4HANA Migration Cockpit användas för överföring, mappning, simulering och validering av affärsdata. En bredare Migration Factory bör komplettera dessa funktioner med gemensamma arbetssätt för dataprofilering, datarensning, avstämning, validering och tydligt dataägarskap.

Integrationskartläggning är minst lika viktig. SAP-miljöer utbyter ofta data med produktionssystem, lagerplattformar, banker, analyslösningar, leverantörer, kunder och tredjepartsapplikationer. Dessa beroenden bör identifieras tidigt och omfattas av end-to-end-testning.

När testkraven har definierats kan återanvändbara och automatiserade testscenarier förvaltas centralt, samtidigt som systemspecifika tester läggs till vid behov. Det minskar det återkommande arbetet utan att begränsa den flexibilitet som krävs för enskilda system.

Molnberedskap och målarkitektur

En SAP S/4HANA-migrering kräver ofta beslut om målinfrastruktur, integrationsmodell, utbyggbarhet och ansvar för den framtida driften.

För organisationer som använder RISE with SAP för att gå mot SAP Cloud ERP Private behöver dessa beslut fattas tillräckligt tidigt för att migreringsvågorna ska kunna genomföras enligt gemensamma principer.

En Migration Factory bör därför etablera gemensamma arkitekturprinciper för integration, konnektivitet, säkerhet, utbyggbarhet och operativt ansvar, samtidigt som systemspecifika undantag kan hanteras där det behövs.

Vilka migreringsstrategier kan en Migration Factory stödja?

En Migration Factory innebär inte att samtliga system måste följa samma migreringsväg.

I ett program med flera system kan olika system följa olika strategier: ett kan konverteras, ett annat konsolideras och ett tredje ersättas genom en nyimplementering.

Migration Factory-modellen tillhandahåller ett gemensamt ramverk för styrning och genomförande runt dessa olika tekniska migreringsvägar.

Hur fungerar migreringsvågor vid en SAP S/4HANA-migrering?

Genom att organisera systemen i migreringsvågor blir det enklare att tydliggöra beroenden, inträdeskriterier, cutover-fönster och ansvar.

Längden på varje våg beror på systemets omfattning, kundanpassad kod, integrationer, datavolymer, affärskritiska processer och vald migreringsstrategi. En återanvändbar sekvens med tydliga in- och utträdeskriterier är därför mer användbar än att utgå från att alla SAP-system kan följa samma fasta tidsplan.

Analys och planering

Innan ett system går in i migreringsflödet brukar teamen:

• analysera det befintliga systemlandskapet och målarkitekturen;

• identifiera tekniska och verksamhetsmässiga beroenden;

• analysera kundanpassad kod;

• utvärdera datakvalitet och migreringsomfattning;

• kartlägga integrationer;

• välja migreringsstrategi;

• definiera krav på testning och cutover;

• planera systemets plats i migreringssekvensen.

Systemen bör prioriteras utifrån verksamhetsmässiga och tekniska beroenden – inte enbart utifrån vad som är tekniskt enklast att genomföra. Processer, automation, mallar och testscenarier kan därefter förbättras innan de tillämpas i större skala.

Genomförande, cutover och stabilisering

Under genomförandet förbereder teamen målmiljön, utför konvertering eller datamigrering, anpassar kundanpassad kod, validerar integrationer och genomför tester.

Inför produktionssättningen behöver organisationen ha en tydlig bild av:

• förväntad driftstoppstid;

• verksamhetsmässiga och tekniska cutover-aktiviteter;

• ansvar och eskaleringsvägar;

• processer för dataavstämning;

• reserv- och återställningsåtgärder;

• övervakning efter produktionssättning.

Efter produktionssättningen övervakas prestanda, gränssnitt, affärsprocesser och datakonsistens tills överenskomna servicenivåer har uppnåtts.

Erfarenheterna från varje våg bör därefter återföras till den gemensamma Migration Factory-modellen.

Vilka är de viktigaste riskerna vid en SAP S/4HANA-migrering?

Standardiserade analyser, kontroller och testprocesser gör det enklare att identifiera återkommande migreringsrisker i flera vågor.

Dolda beroenden och komplexa integrationer

I mogna SAP-landskap kan odokumenterade beroenden upptäckas sent i migreringscykeln och orsaka avbrott i sammanhängande affärsprocesser under cutover.

Historiska implementationer, lokala applikationer, företagsförvärv och tillfälliga gränssnitt kan ha skapat kopplingar som inte längre är fullt dokumenterade i den aktuella arkitekturen. När dessa beroenden sträcker sig över både SAP- och icke-SAP-system kan en tekniskt lyckad migrering ändå störa produktion, logistik, rapportering, betalningsflöden eller andra kritiska processer.

En Migration Factory bidrar till att minska denna risk genom gemensamma krav på kartläggning och validering av beroenden för samtliga migreringsvågor, medan systemspecifika integrationer hanteras av respektive team.

Kundanpassad kod och äldre data

All kundanpassad utveckling behöver inte följa med till SAP S/4HANA.

Om kundanpassad kod inte analyseras tidigt kan behovet av anpassningar öka sent i migreringscykeln. Detsamma gäller äldre data med låg kvalitet eller information som inte längre behövs, eftersom den kan föra över befintlig komplexitet till målmiljön.

En Migration Factory kan etablera gemensamma kriterier för anpassning av kundanpassad kod, datarensning, validering och ägarskap mellan olika system och affärsenheter. Det hjälper teamen att hantera återkommande kvalitetsproblem på ett enhetligt sätt utan att behöva upprepa samma analys för varje migreringsvåg.

Säkerhet, regelefterlevnad och verksamhetskontinuitet

Säkerhet och regelefterlevnad blir svårare att styra konsekvent när SAP-migreringar omfattar flera system, integrationer, molntjänster och jurisdiktioner. Dessa områden behöver därför vara en integrerad del av migreringsdesignen redan från början.

För svenska organisationer inom sektorer och verksamheter som omfattas av cybersäkerhetslagen behöver migreringsplaneringen även ta hänsyn till aktuella krav på cybersäkerhet. Sveriges cybersäkerhetslag trädde i kraft den 15 januari 2026 som en del av genomförandet av NIS2. Den svenska regeringen beskriver de nya kraven i sitt officiella pressmeddelande.

Beroende på organisation och sektor kan migreringsplaneringen därför behöva omfatta bland annat åtkomstkontroller, incidenthantering, motståndskraft, tredjepartsberoenden och kontinuitet i kritiska tjänster.

Dataskydd är också relevant när molntjänster och gränsöverskridande behandling av personuppgifter ingår. Integritetsskyddsmyndigheten (IMY) anger att överföring av personuppgifter utanför EU/EES måste uppfylla GDPR krav för tredjelandsöverföring. Se IMY vägledning.

Genom att definiera gemensamma kontroller centralt blir det enklare att upprätthålla enhetliga krav på åtkomst, motståndskraft, tredjepartsrisk och regelefterlevnad i samtliga migreringsvågor.

Hur organiseras en SAP Migration Factory?

En Migration Factory behöver ha en tydlig ansvarsfördelning mellan centrala funktioner och det systemspecifika genomförandet.

Central Migration Factory

Det centrala teamet ansvarar vanligtvis för:

• styrning och migreringsstandarder;

• principer för målarkitektur;

• verktyg och automation;

• återanvändbara mallar och processer;

• kvalitetssäkring;

• planering och rapportering mellan migreringsvågor.

Teamets uppgift är att etablera den gemensamma leveransmodellen och säkerställa att migreringsvågorna följer enhetliga kontroller och arbetssätt.

Team för migreringsvågor

Team för respektive migreringsvåg ansvarar för det systemspecifika genomförandet, bland annat:

• konverterings- eller implementationsaktiviteter;

• datamigrering;

• anpassning av kundanpassad kod;

• integrationsarbete;

• systemspecifik testning;

• teknisk cutover.

De arbetar inom det gemensamma ramverket men hanterar samtidigt de förutsättningar som gäller för det system som migreras.

Verksamhets- och platsansvariga

Verksamhets- och lokala team ansvarar fortsatt för att validera lokala processer och den operativa beredskapen.

Deras medverkan är särskilt viktig för produktion, logistik, ekonomi, lokala applikationer, cutover-planering och slutligt verksamhetsgodkännande.

Vilken affärsnytta kan en Migration Factory bidra till?

Kostnadseffektivitet och leveranstakt i en Migration Factory påverkas av det befintliga systemlandskapet, migreringens omfattning och kvaliteten i genomförandet.

Den huvudsakliga affärsnyttan ligger i att minska behovet av att etablera samma projektstrukturer flera gånger inom en större migreringsportfölj och att skapa ett mer konsekvent genomförande från en migreringsvåg till nästa.

I komplexa SAP-landskap kan ett S/4HANA-program dessutom skapa möjlighet att avveckla föråldrade system och kundanpassningar, förbättra datakvaliteten, konsolidera överlappande processer och minska onödig komplexitet i systemlandskapet. För svenska koncerner med verksamhet på flera marknader och genom flera juridiska enheter kan detta göra det enklare att kombinera koncerngemensamma standarder med lokala verksamhetskrav.

En renare och mer standardiserad ERP-kärna kan också förenkla framtida satsningar på automation, avancerad dataanalys, integrationer och AI-baserade funktioner genom att minska den tekniska skuld och äldre komplexitet som nya initiativ annars behöver hantera.

Så stödjer LeverX storskalig SAP S/4HANA-migrering

LeverX stödjer organisationer genom hela migreringsresan – från analys av systemlandskapet och migreringsstrategi till tekniskt genomförande, testning, cutover och stabilisering efter produktionssättning.

Våra team arbetar med:

• SAP S/4HANA-systemkonvertering och selective data transition;

• analys av systemlandskap och readiness;

• analys och anpassning av kundanpassad kod;

• datamigrering och validering;

• kartläggning och testning av integrationer;

• migreringsautomation och återanvändbara acceleratorer;

• cutover, stabilisering och löpande förvaltning av SAP-applikationer.

När olika system kräver olika migreringsstrategier kan dessa aktiviteter samordnas inom ett gemensamt Migration Factory-ramverk i stället för att hanteras som fristående och oberoende projekt.

Planerar ni en SAP S/4HANA-migrering som omfattar flera system? Kontakta LeverX för att diskutera hur migreringsvågorna kan struktureras, genomförandet standardiseras och beroenden hanteras i ert SAP-landskap.