SAP S/4HANA Migration Cockpit: styrkor och begränsningar

Ska du över till SAP S/4HANA är Migration Cockpit verktyget SAP vill att du använder. Det är efterföljaren till gamla LSMW, levereras via Fiori-appen Migrate Your Data och kommer med hundratals fördefinierade migreringsobjekt – kunder, leverantörer, material, öppna poster och så vidare – med fältmappning och validering inbyggt.

Det är genuint användbart. Men det är ett laddningsramverk, inte ett trollspö: det löser transporten av data, inte kvaliteten. Här är en ärlig titt på vad det gör bra och var det tar slut. Allt nedan utgår från cockpit i SAP S/4HANA 2025.

Två sätt att migrera

Cockpit ger dig två angreppssätt, och att välja rätt från början spelar roll.

1. Migrera data via staging-tabeller

Staging-tabeller är det flexibla alternativet. Cockpit skapar en uppsättning staging-tabeller – tekniskt benämnda /1LT/DS… – som du fyller med din källdata innan den överförs in i S/4HANA. Tabellerna kan ligga på två ställen:

• Lokalt S/4HANA-databasschema – cockpit genererar tabellerna i målsystemets interna ABAP-schema.
• Fjärranslutet SAP HANA-databasschema – ett dedikerat schema, eventuellt på en separat tenant, anslutet via DBCO. Det är detta som låter ett externt ETL-verktyg skriva rakt till tabellerna. (SAP begränsar schemat till enbart migreringsbruk.)

Du kan fylla tabellerna på två sätt:

• Ladda upp de mallfiler som cockpit genererar per migreringsobjekt. Standard- och rekommenderat format är XML (en Excel 2003 XML-arbetsbok per objekt, med ett blad per datastruktur); CSV stöds men är ett expertalternativ (RFC 4180, UTF-8, en fil per datastruktur).
• Fylla staging-tabellerna direkt – med SQL, ett ETL-verktyg som SAP Data Services eller egna skript. Laddar du tabellerna så, kör cockpits konsistenskontroll själv; filuppladdningar får den kontrollen automatiskt, direktladdningar inte.

När tabellerna är fyllda sköter cockpit mappning, simulering, validering och själva överföringen in i S/4HANA.

Styrkor: hanterar stora volymer långt bättre än filuppladdning, låter dig förbereda och städa data med egna verktyg innan den ens rör SAP, och stödjer ett iterativt flöde: "fyll → simulera → rätta → ladda om". Det här är mitt förstaval för alla migreringar av någon storlek.

Begränsningar: du behöver databasåtkomst och någon som är bekväm med SQL/ETL för att fylla tabellerna; det kräver mer förarbete än direktmetoden. Håll koll på de praktiska kanterna också – Excel-mallen klarar max 15 siffror per numeriskt fält, och uppladdade filer har storleksgränser (100 MB per XML-fil, 100 MB per zip).

2. Migrera data direkt från ett SAP-system

Direktmetoden läser data rakt från ett käll-SAP-system via en RFC-anslutning – inga kalkylblad, ingen manuell filhantering. Du väljer migreringsobjekt, sätter urvalskriterier (oftast organisatoriska enheter som bokföringskretsar), och cockpit extraherar och överför i ett flöde. Källan får till och med vara icke-Unicode; konverteringen till S/4HANA-datamodellen sker automatiskt vid laddning.

Det fungerar bara för specifika scenarier som stöds, var och en med en lägsta release:

• SAP ERP / ECC → S/4HANA (ERP 6.0 / NetWeaver 7.0 och uppåt)
• SAP Apparel and Footwear (AFS) → S/4HANA (AFS 6.0)
• SAP EWM → decentraliserad EWM (EWM 5.1)
• SAP CRM → S/4HANA for Customer Management (CRM 7.0)
• SAP APO SPP → eSPP (SCM 7.14)

Du kan inte använda ett annat S/4HANA-system som källa, och källan behöver DMIS-add-on installerat i en kompatibel version.

Styrkor: minimalt förarbete, ingen manuell dataförberedelse, och kunskapen om SAP-till-SAP-fält ligger inbyggd i de fördefinierade objekten. När källan är SAP och datan redan är någorlunda ren är det här den snabbaste vägen. Du kan också välja att låta en direktöverföring gå via staging-tabeller som mellanlagring om du vill ha en plats att inspektera eller justera datan på vägen.

Begränsningar: det fungerar bara från SAP-källsystem som stöds, och du är bunden till den fördefinierade extraktionslogiken och urvalsmöjligheterna. Det finns betydligt mindre utrymme att transformera eller städa data på vägen – det som finns i källan är i stort sett det du får. Ett projekt är knutet till ett källsystem; byter du källa krävs ett nytt (eller kopierat) projekt.

Projektlivscykeln team underskattar

Det här står inte i marknadsföringen, men det formar din tidplan. Migreringsprojekt kan bara skapas i ett utvecklingssystem och sedan transporteras – dev → test → produktion – via Migration Object Modeler (LTMOM). Några konsekvenser värda att planera för:

• Utvecklingspaketet måste ha prefix Y/Z; ett lokalt $TMP-paket går inte att transportera.
• Du kör normalt flera testcykler, var och en i en färsk kopia av produktion, innan den skarpa laddningen. Varje cykel får sitt eget projekt som bär med sig föregående rättningar.
• Mappningsvärden transporteras inte med projektdefinitionen – men du kan ladda ner mappningsvärden från en cykel och ladda upp dem i nästa, så du slipper mappa om från noll varje varv.
• Efter en S/4HANA-uppgradering rekommenderar SAP att bygga nya projekt snarare än att återanvända gamla.

Budgetera för itereringen, inte bara den slutliga laddningen.

Vad cockpit gör bra

• Fördefinierat innehåll. Hundratals färdiga migreringsobjekt med fältmappningar och kontroller – du bygger inte från noll.
• Mappning och värdemappning. Lös value mapping-uppgifter (legacy-värde → S/4HANA-värde) och fixed value-uppgifter (standardvärden) centralt och återanvänd dem.
• Simulering och validering. Simulera överföringar och rensa fel innan du skriver in skarp data. Meddelanden är typade (fel / varning / lyckat / info) och sparas i 180 dagar.
• Beroendekännedom. Objekten känner sina föregångare; vyn Sequence Information och appen Explore Migration Objects hjälper dig ladda i rätt ordning.
• Parallellitet. Job Management låter dig styra bakgrundsjobb (15 som standard) per projekt och per objekt för att driva volym.
• Ingen ABAP för standardobjekt. Verksamhetsdriven migrering är realistisk för standardomfånget.

Var det tar slut – och du tar över

Det är här team underskattar arbetet. Cockpit laddar in vad du än ger det; det säger inte till att datan var fel från början.

• Datakvaliteten är fortfarande ditt ansvar. Profilering, dubbletthantering och att definiera "tillräckligt bra" sker före cockpit – helst under discovery, inte vid laddning.
• Egna objekt och fält kräver arbete i Migration Object Modeler (LTMOM) – egna migreringsobjekt, Check for Custom Fields på standardobjekt, och egna källkodsregler (som kräver extra S_DEVELOP-behörigheter). Allt utöver standard kräver riktigt arbete.
• Det är inte ett fullständigt ETL-verktyg. Tung transformation, komplexa affärsregler och logik mellan objekt hanteras bättre uppströms.
• Avstämningen är din. Cockpit bekräftar att en laddning lyckades tekniskt; att bevisa att den migrerade datan stämmer med källan – antal, summor, sign-off – är fortfarande en separat, manuell disciplin.
• Delta-hantering är begränsad. Planera cutover-ordningen (bulk vs delta) medvetet; förvänta dig inte att verktyget sköter det åt dig.
• Efterlevnaden är din. Att migrera personuppgifter som borde ha raderats kan i sig vara olaglig behandling. Cockpit erbjuder en datalagringsperiod på avslutade projekt, men beslutet om vad som får flyttas är ditt.

Värt att veta innan du börjar

En kort checklista från praktiken som besparar dig huvudvärk senare:

• Behörigheter. Att överföra data kräver rollen SAP_CA_DMC_MC_USER (plus SAP_BR_CONFIG_EXPERT_DATA_MIG på frontend); LTMOM-arbete kräver SAP_CA_DMC_MC_DEVELOPER; direktöverföring kräver en RFC-användare med SAP_DMIS_MC_DT_REMOTE i källan.
• Note Analyzer. Kör transaktion CNV_NA_MC (SAP Note 3016862) regelbundet för att bekräfta att relevanta korrektionsnoter finns på plats – cockpit och dess DMIS-komponenter rör sig snabbt.
• Projekt bor i dev. Du kan inte skapa dem i QA- eller produktionssystem.

Sammanfattning

Migration Cockpit är rätt verktyg för att ladda in data i S/4HANA, och valet mellan staging-tabeller (flexibelt, volymvänligt, egen förberedelse) och direktöverföring (snabbt, SAP-till-SAP, mindre kontroll) bör vara ett medvetet beslut. Men cockpit är sista milen. Arbetet som avgör om migreringen lyckas – att förstå källan, rätta kvaliteten, definiera scope och stämma av resultatet – ligger tydligt utanför verktyget.

Planerar ni ett S/4HANA-byte och väger staging mot direktöverföring? Hör av dig – jag berättar gärna hur jag arbetar.

---

Referens: den officiella dokumentationen från SAP Help Portal som artikeln bygger på finns här som PDF — SAP S/4HANA Migration Cockpit – Data Migration (2025 FPS01).