Kezdjük a legfontosabbal, mert erről szól a legtöbb félreértés: az Azure Data Factory megszűnésére nincs bejelentett dátum. Nincs határidő, nincs kényszerítés, a meglévő pipeline-ok futnak tovább, és az ADF a Fabric Data Factoryval párhuzamosan üzemeltethető. Egy ideig keringett egy felugró üzenet arról, hogy 2026 júliusától nem lehet majd új pipeline-t létrehozni – ilyen korlátozás nem lépett életbe, és hivatalosan sosem került bejelentésre.

Akkor miért beszél mégis mindenki a migrációról? Mert a fejlesztési irány egyértelmű. Az új képességek a Fabric Data Factoryban jelennek meg először, a Microsoft pedig magába az ADF-be építette bele a migrációs eszközt. Ez elég beszédes döntés – nem határidő, de irány.

Mit tud a beépített migrációs eszköz

A márciusban bejelentett, jelenleg előzetes állapotú migrációs eszköz két helyről indítható: közvetlenül az ADF szerkesztőfelületéről vagy egy Fabric munkaterületről. A logikája felmérés-központú, és ez a legjobb tulajdonsága. Az eszköz végigpásztázza a factoryt, és minden pipeline-t – valamint azon belül minden aktivitást – besorol egy készültségi státuszba, tehát látszik, melyik pipeline mozdítható ma, melyik nem, és pontosan melyik aktivitás okozza a problémát. Az egész folyamat csak olvasható, a factoryhoz nem nyúl hozzá, az eredmény pedig CSV-be exportálható – nagyobb portfólióknál ez gyakorlatilag kötelező, mert onnantól ez lesz a migrációs terv gerince.

Van egy köztes lépés is, amit érdemes ismerni: a mount. Ezzel az ADF-példány hivatkozhatóvá válik egy Fabric munkaterületen belül anélkül, hogy bármit migrálnánk, másolnánk vagy módosítanánk az ADF-környezeten. Aki fokozatosan akar átállni, annak ez a köztes állapot sokat ér.
Maga a migráció során a linked service-ek Fabric connectionökké konvertálódnak, a triggerek pedig alapértelmezés szerint kikapcsolva érkeznek meg. Ez utóbbi apróságnak tűnik, de nem az: azt jelenti, hogy a migrált pipeline nem kezd el magától futni a validáció előtt. Aki látott már éles környezetben véletlenül duplán induló betöltést, tudja értékelni. Az eszköz egyébként ingyenes, és a Microsoft nyílt forráskódú kiegészítőket is ad mellé a Fabric Toolboxban – egy PowerShell-alapú migrációs asszisztenst ARM-sablonokhoz, és egy assessment eszközt a munkaterületek leltározására.

És most a valóság

Eddig szólt a hivatalos leírás; a gyakorlat kicsit másképp néz ki. A felmérés tényleg jó – ingyenes, kockázatmentes, és az első hasznos szám, amit az ember kap. Onnantól viszont a dolog gyorsan kézivezérlésbe fordul. Az eszköz előzetes állapotban van, és ez nem formalitás: az aktivitásszintű lefedettség hiányos, a konnektorok átkonvertálása után szinte mindig marad kiigazítanivaló, és minél régebbi és egyedibb egy factory, annál nagyobb a manuális rész aránya. Sokatmondó, hogy még a Microsoft által idézett sikersztoriban is – ahol 300 pipeline, 500 tábla és 450 GB adat mozgott át, nagyjából 66%-os ráfordításcsökkenéssel – külön szerepel, hogy a konnektoroknál kisebb kiigazításokra szükség volt.

Ez a „kisebb kiigazítás” az, ami a valóságban a projekt idejének a nagyobbik felét elviszi. Konkrétan azért, mert a migráció nem a pipeline-ok átmásolásáról szól. Arról szól, hogy a paraméterezés, az ütemezési logika, a hibakezelés, a jogosultságok és a monitorozás egy másik platform szabályai szerint épüljön újra – miközben a régi rendszernek is futnia kell. Erre az eszköz nem ad választ, mert nem is tud: nem ismeri a szervezet konvencióit, nem tudja, melyik pipeline kritikus, és nem dönti el, hogy egy elavult megoldást átvigyünk-e vagy inkább most javítsunk ki.

Mi megy át simán, és mi nem

A klasszikus adatmozgató és orchestrationlogika többsége problémamentesen átvihető: a Copy activity, a control flow, a paraméterezés, az ütemezés ismerős terepen mozog, hiszen a Fabric pipeline-koncepció közvetlenül az ADF-ből nőtt ki.

Három terület viszont külön vizsgálatot igényel. A dataflow-ok – vagyis az ADF vizuális, Spark alapú transzformációi – átvitele továbbra sem magától értetődő. Van rá egy júniusban megjelent, nyilvános előzetes útvonal, de annyi hiányossággal, hogy ma nem érdemes rá éles migrációs tervet építeni: a komplexebb, újrafelhasználható elemekre épülő és a szigorúbb hálózati izolációt igénylő transzformációk egyelőre nem vihetők át. A transzformációs logika átemelése marad a migráció legmunkaigényesebb része. Az SSIS-csomagok futtatására megjelent az Invoke SSIS Package activity, szintén előzetesben – aki felhőben lakó, stock komponensekből épült csomagokkal dolgozik, annak ma is használható, akinek a csomagjai on-prem forráshoz nyúlnak, annak egyelőre nem. A hitelesítés viszont jó hír: a Service Principal és a Workspace Identity támogatása minden pipeline aktivitáshoz általánosan elérhetővé vált, és ez az a pont, ahol a migráció nem csak áthelyezés, hanem javítás is – a személyes fiókokra épülő kapcsolatokat pont ilyenkor érdemes kivezetni.

A számla is más lesz

A költségmodell megváltozik, és ezt előre kell tisztázni, nem utólag. Az ADF fogyasztásalapú: azért fizetünk, amit futtatunk. A Fabric kapacitásalapú: egy fix keretet veszünk, és abból gazdálkodunk. Ez nem egyszerűen „olcsóbb vagy drágább” kérdés, hanem más logika – kiszámíthatóbb, de nem automatikusan kevesebb, és ha a kapacitás alá van méretezve, torlódás lesz belőle. A migrációs terv része kell legyen egy kapacitásbecslés is, lehetőleg valós terhelési adatok alapján, nem érzésre.

Hogyan érdemes nekiállni

Az első lépés a felmérés. Ez néhány kattintás, és ad egy első képet arról, hogy a portfólió mekkora része mozdítható ma. Amit viszont nem ad, az a terv: az eredmény egy státuszokkal és hibajelzésekkel teli lista, amiből még nem következik sem ütemezés, sem költségbecslés, sem az a döntés, hogy mit viszünk át változatlanul és mit építünk újra.

Utána egy nem kritikus, közepesen összetett pipeline-t érdemes végigvinni teljesen: migrálás, validálás, párhuzamos futtatás, monitorozás. Ez az a néhány nap, amin minden későbbi becslés alapulni fog – és ami megmutatja, hol tér el a dokumentáció a valóságtól.

A párhuzamos üzem ne ideiglenes kellemetlenség legyen, hanem tervezett szakasz. Ma nincs határidő, tehát nincs ok arra, hogy a régit előbb kapcsoljuk le, mint hogy az új bizonyított volna. Arra viszont nem érdemes építeni, hogy ez örökre így marad. Az a bizonyos felugró üzenet a júliusi korlátozásról végül nem lett valóság, de önmagában jelzi, hogy a kérdés napirenden van valahol – és a fejlesztési erőforrások iránya sem hagy sok kétséget. Egy-két éves párhuzamos üzemet ma nyugodtan lehet tervezni; ötéveset már kockázatos.

A nehezét pedig hagyjuk tudatosan a végére. Amelyik pipeline szigorú hálózati izolációt igényel, egyedi fejlesztésű komponensre épül vagy összetett, újrafelhasznált transzformációs logikát használ, arra ma nincs jó válasz. Ezekre nem kerülőmegoldást kell építeni, hanem megvárni, amíg a platform beéri őket.

Amikor megvan a lista

Itt kezdődnek az igazi kérdések. Melyik pipeline-t érdemes egyáltalán átvinni, és melyiket használnánk ki inkább arra, hogy végre kidobjuk? Mennyi kapacitást kell venni ahhoz, hogy az éjszakai betöltés ne torlódjon, de ne is fizessünk üresen álló keretért? Mit csinálunk azokkal a dataflow-okkal, amikre ma nincs migrációs út – megvárjuk a platformot, vagy újraépítjük? Meddig fusson a párhuzamos üzem, és mi az a pont, ahol ki lehet mondani, hogy az új rendszer bizonyított? Ezekre nem az eszköz válaszol. Ezekre az válaszol, aki már látta, mi történik, amikor egy ilyen terv találkozik egy éles környezettel – ahol a betöltésnek reggel hatra kész kell lennie, és ahol a „majd kijavítjuk” nem opció.

Ha a szervezet most ott áll, hogy megvan a felmérés eredménye, de nem világos, mi legyen belőle, érdemes leülni egy beszélgetésre. Nem kell hozzá előzetes döntés, elég a lista. Abból már látszik, hol van néhány hetes munka, hol több hónapos, és hol az, hogy idén jobb hozzá sem nyúlni. Mert a migráció ma már nem elvi kérdés, hanem ütemezési. Egy éve még az volt a kérdés, hogy egyáltalán lehetséges-e; ma az, hogy a portfólió melyik része mikor kerül sorra – és melyik az, amelyik idén még biztosan nem.