Migrering
Från Apps 9/10 till IFS Cloud
Senast kontrollerad
När ni planerar flytten till IFS Cloud behöver integrationerna få en egen genomgång. Här går vi igenom hur ni kan sortera arbetet, vilka frågor som är bra att ställa och hur ett gemensamt register hjälper er vidare.
Kontrollerad mot Decision Guide (26R1) · 2026-08-30
Kontrollerad mot Technical changes related to IFS Cloud (25R2) · 2026-08-30
Integrationerna dokumenterades inte samtidigt som de byggdes
Det som gör migreringen svårbedömd är sällan tekniken. Det är att flödena byggdes under många år, av olika personer, med olika förutsättningar och under olika tidspress. Nätverksbilden visar en pil; den säger inget om vilken verksamhetslogik som ligger inuti pilen.
Ett integrationsregister gör det lättare att uppskatta arbetet och förklara vad bedömningen bygger på. Börja med det ni vet och samla frågorna som behöver redas ut.
Varje flöde hamnar i en av tre högar
Överlever
Standardiserade anrop med tydliga kontrakt. Går ofta att bedöma utan att börja bygga om, men bedömningen kräver att kontraktet faktiskt är dokumenterat.
Behöver arbetas om
Projektioner, fält och events som behöver jämföras mot målmiljön. Arbetet är avgränsat, men ordningen spelar roll: mottagaren måste testas, inte bara avsändaren.
Behöver ritas om
Hårt kopplade flöden och dold logik. Här är frågan inte hur koden flyttas utan var ansvaret ska ligga mellan IFS Cloud och systemen omkring.
Sorteringen är enkel att beskriva och svår att göra, av ett enda skäl: den förutsätter att man vet vad flödet gör. Det är den uppgiften registret tar fram.
Vad som går att ta reda på utan leverantör
- Vad exponerar er nuvarande miljö? Ett uttag ur API Explorer, sparat versionerat, är jämförbart mot målmiljön senare.
- Vilka flöden går förbi API-lagret? Direkt databasåtkomst och delade filkataloger har inget kontrakt att migrera. De blir utveckling.
- Vilka projektioner används av både gränssnitt och integration? Kopplingen är designad, men den gör att en gränssnittsändring kan påverka en integration. Se Projektioner och OData.
- Vad förutsätter varje flöde om mäklaren? Köhantering och felhantering försvinner inte för att anropet i andra änden blir REST. Se IFS Connect.
Ta med underlaget till planeringen
En användbar tidplan börjar med era flöden, beroenden och testresultat. Samla öppna frågor och ansvariga i registret, så blir det lättare att prata om vad som behöver göras och i vilken ordning.
Uppskatta arbetet när ni har provat målbilden. Då kan ni skilja på verifierade lösningar och sådant som fortfarande behöver undersökas.
Dokumentationen bakom vägvalen finns under Källor och metod.
En rad före flytten, en verifierad målbild efteråt
Illustrativt exempel: artikeluppgifter skickas till ett lager varje natt. Den första inventeringen säger ”batchjobb och fil”. Det lämnar format, ägare och felväg öppna. Nästa steg är att följa en testartikel och spara det kontrakt flödet faktiskt använder.
- Nuvarande miljö
- Anteckna jobb, filformat, mottagare och vem som märker att en leverans saknas.
- Föreslagen målbild
- Beskriv den API-, meddelande- eller fillösning ni vill prova. Markera den som förslag tills den är testad.
- Verifiering
- Jämför samma testartikel, fält och felvillkor i målmiljön. Spara resultat och vem som godkände det.
- Beslut
- Behåll, arbeta om eller rita om flödet utifrån provet. Lägg kvarvarande frågor på egna rader i planen.
Fyll i integrationsregistret (CSV) och länka varje rad till testunderlaget. Exemplet är en arbetsgång, inte ett löfte om att ett visst filflöde kan ersättas av en viss standardprojektion.
Gör releasekontrollen till en del av testet
- Spara nuvarande release och ett maskerat kontraktsexempel.
- Välj målrelease i releaseöversikten och följ dess dokumentationslänkar.
- Kontrollera projektion och operation i målmiljöns API Explorer och följ kontraktskontrollen före uppgradering.
- Prova lyckad körning, mottagarfel och återkörning. Spara resultatet innan ni bokar övergången.