Przykład zastosowania: Migracja Informatica PowerCenter

To pełna historia tego, jak inżynier danych z Polkomtela bierze jeden stary przepływ pracy Informatica PowerCenter — zbudowany lata temu, trudny do zmiany i kosztowny w utrzymaniu — i zamienia go w nowoczesny potok danych DataFlow AI działający w chmurze. Śledzimy każdy ekran, każde kliknięcie i każdą decyzję, wyjaśnione tak, by mogła to zrozumieć osoba, która nigdy nie dotknęła bazy danych.

Poznaj ludzi i problem

Przedstawmy Marka. Marek jest inżynierem danych w Polkomtel Plus, polskiej firmie telekomunikacyjnej. Jego zadaniem jest dopilnowanie, by informacje co noc poprawnie przepływały między licznymi systemami komputerowymi firmy, tak aby następnego ranka biznes miał świeże raporty.

Od ponad piętnastu lat Polkomtel przenosi te dane za pomocą narzędzia o nazwie Informatica PowerCenter. Wyobraź sobie PowerCenter jako bardzo starą, bardzo niezawodną furgonetkę dostawczą. Robiła swoją robotę przez długi czas, ale coraz trudniej znaleźć do niej części zamienne, paliwo jest drogie, a nie potrafi jeździć po nowych autostradach (chmurze). Polkomtel płaci gdzieś między 1,2 miliona a 2 milionami dolarów rocznie tylko za licencję, by utrzymać tę furgonetkę na drodze.

Polkomtel zdecydował się wycofać tę furgonetkę. Mają 500 lub więcej przepływów pracy PowerCenter — 500 osobnych „tras dostaw" — które wszystkie trzeba przenieść na nowoczesną, opartą na chmurze platformę o nazwie DataFlow AI. Zadaniem Marka jest wykonanie tego przeniesienia, przepływ pracy po przepływie pracy. Wykonanie 500 z nich ręcznie zajęłoby lata. Dlatego DataFlow AI ma wbudowanego pomocnika, Centrum Migracji, które wykonuje większość pracy automatycznie i prosi Marka o pomoc tylko tam, gdzie człowiek jest naprawdę potrzebny.

Czym właściwie jest przepływ pracy Informatica PowerCenter

Zanim Marek będzie mógł przenieść przepływ pracy, warto zrozumieć, z czego się on składa. PowerCenter organizuje swoją pracę w kilka zagnieżdżonych warstw. Wyobraź sobie książkę kucharską.

A więc workflow PowerCenter zawiera sesje, każda sesja uruchamia mapowanie, a każde mapowanie jest łańcuchem źródeł → transformacji → celów połączonych ze sobą przez konektory. DataFlow AI używa dokładnie tej samej idei, ale nazywa elementy węzłami (pudełka) i krawędziami (strzałki), złożonymi w potok danych.

Przykład, który będziemy śledzić: wf_SAP_Replika

Pierwsza migracja Marka to prawdziwy przepływ pracy Polkomtela o długiej nazwie: wf_SAP_Replika_l_BIURO_SPRZEDAZY_PLK. Dla skrótu będziemy go nazywać wf_SAP_Replika.

Mówiąc prosto, ten przepływ pracy wykonuje jedno proste, bardzo powszechne zadanie: co noc kopiuje tabelę „biura sprzedaży" z bazy danych SAP HANA i zapisuje świeżą kopię do hurtowni danych Teradata. Jest to replikacja z pełnym odświeżeniem — opróżnij cel, skopiuj wszystko ponownie. Nie ma tu sprytnej matematyki, nie ma łączenia tabel; jest to w większości proste kopiowanie.

Ponieważ jest tak prosty, Centrum Migracji spodziewa się przekonwertować ten przepływ pracy z około 95% automatycznym sukcesem — niemal bez pracy człowieka. Zadania replikacji takie jak to stanowią mniej więcej 35% całego zasobu Polkomtela, więc poprawne ich wykonanie to duża, szybka wygrana. (Na drugim biegunie znajduje się przepływ pracy o nazwie wf_E112 z 7 mapowaniami i ponad 40 transformacjami, który automatycznie konwertuje się tylko w 68–75% — wspomnimy o nim później jako o kontraście.)

Krok 1 — Wyeksportuj przepływ pracy z PowerCenter

Centrum Migracji nie potrafi czytać wewnętrznego repozytorium PowerCenter bezpośrednio. Potrzebuje przepływu pracy jako pliku. PowerCenter potrafi zapisać dowolny przepływ pracy jako plik XML — XML to po prostu ustrukturyzowany format tekstowy, trochę jak bardzo uporządkowany, głęboko wcięty konspekt.

Marek otwiera PowerCenter Repository Manager, znajduje folder zawierający wf_SAP_Replika, klika prawym przyciskiem myszy na przepływ pracy i wybiera Export Objects. PowerCenter zapisuje plik o nazwie mniej więcej wf_SAP_Replika.xml.

Wewnątrz ten plik XML ma zagnieżdżony kształt, który Centrum Migracji potrafi odczytać:

REPOSITORY
 └─ FOLDER
     └─ MAPPING                       (the recipe — has a NAME and DESCRIPTION)
         ├─ SOURCE  → SOURCEFIELD*     (the cupboard and its columns)
         ├─ TARGET  → TARGETFIELD*     (the serving plate and its columns)
         ├─ TRANSFORMATION             (each cooking step — has a NAME and TYPE)
         │    ├─ TRANSFORMFIELD*       (the column-level logic — the EXPRESSION)
         │    └─ TABLEATTRIBUTE*       (the step's settings, as name/value pairs)
         └─ CONNECTOR                  (the arrows wiring steps together)

Kilka praktycznych kwestii, o których Marek pamięta:

• Plik musi mieć rozszerzenie .xml — tak Centrum Migracji rozpoznaje eksport z PowerCenter.
• Plik musi mieć 50 MB lub mniej. wf_SAP_Replika jest maleńki, więc nie ma z tym problemu; tylko ogromne eksporty z wieloma mapowaniami zbliżają się do limitu.
• Jeśli przepływ pracy używa pliku parametrów (osobny plik .parm przechowujący wartości takie jak nazwy baz danych i zakresy dat), Marek eksportuje również ten plik — te wartości będą później potrzebować nowego domu w DataFlow AI.

Krok 2 — Prześlij plik do Centrum Migracji

Marek loguje się do DataFlow AI pod adresem https://dataflow.polkomtel.internal, używając zwykłego pojedynczego logowania Polkomtela (ta sama nazwa użytkownika i hasło co przy logowaniu do Windows). W lewym panelu bocznym klika Migracja, co otwiera Centrum Migracji i przenosi go do Kreatora Importu.

Kreator Importu ma dużą strefę upuszczania. Marek przeciąga wf_SAP_Replika.xml na nią (lub klika Przeglądaj i wybiera plik). W momencie, gdy plik ląduje, Centrum Migracji wykonuje kilka szybkich kontroli bezpieczeństwa, zanim przyjmie zadanie:

1. Czy nazwa pliku jest obecna, a rozszerzenie dozwolone? Musi to być .xml, .yxmd lub .dtsx. .xml jest na liście, więc wf_SAP_Replika.xml przechodzi pomyślnie.
2. Czy plik ma mniej niż 50 MB? Tak.
3. Tworzy zadanie migracji — śledzone zadanie z własnym identyfikatorem — i natychmiast oznacza je jako UPLOADED. Surowy plik jest zapisywany w bezpiecznym folderze roboczym, a rekord zadania jest zapisywany na dysku, więc nic nie ginie, jeśli usługa zostanie ponownie uruchomiona.

Od tego jednego przesłania Centrum Migracji uruchamia teraz cały potok konwersji automatycznie, za jednym zamachem. Marek nie klika niczego więcej; po prostu obserwuje zmianę statusu. Zadanie przechodzi przez następujące etapy:

UPLOADED → PARSING → PARSED → CONVERTING → VALIDATING → VALIDATED
         → COMPLETED  |  COMPLETED_WITH_WARNINGS  |  FAILED

Kolejne sekcje przeprowadzają przez to, co tak naprawdę robi każdy z tych etapów.

Krok 3 — Parsowanie: odczytanie przepisu na wspólny język

Pierwsza prawdziwa praca to parsowanie. Centrum Migracji wybiera odpowiedni czytnik dla pliku — dla pliku .xml jest to Parser PowerCenter — a status zadania zmienia się na PARSING.

Parser czyta plik XML i tłumaczy go na wewnętrzny, neutralny wobec narzędzi opis przepływu pracy. Ten wewnętrzny opis ma ten sam kształt niezależnie od tego, z jakiego starszego narzędzia pochodzi plik (PowerCenter, Alteryx, SSIS, DataStage). To jest właśnie sprytny trik: tłumacząc najpierw cztery różne starsze formaty na jeden wspólny kształt, DataFlow AI potrzebuje potem tylko jednego silnika konwersji.

Ten wspólny opis jest zbudowany z kilku prostych elementów:

Dla wf_SAP_Replika parser znajduje jedno mapowanie. Wewnątrz niego odczytuje:

• SOURCE wskazujące na tabelę biura sprzedaży SAP HANA, ze wszystkimi jej kolumnami. Zapisuje również typ bazy danych źródła, schemat (nazwę właściciela) i nazwę połączenia.
• TARGET wskazujące na tabelę Teradata, która otrzyma kopię.
• Niewielką garść TRANSFORMATIONS — dla czystej replikacji jest to głównie Source Qualifier (krok, który faktycznie odczytuje ze źródła) i być może prosta Expression przepuszczająca kolumny.
• CONNECTORS łączące źródło → transformację → cel.

Jeśli cokolwiek w pliku XML jest wadliwe i parser nie potrafi tego zrozumieć, zadanie zatrzymuje się tutaj i jest oznaczane jako FAILED, z jasnym komunikatem. Dla czystego eksportu Marka parsowanie kończy się sukcesem, a status zmienia się na PARSED.

Krok 4 — Konwersja: zamiana każdego kroku PowerCenter w węzeł DataFlow

Teraz status zadania zmienia się na CONVERTING i tutaj mieszka prawdziwa inteligencja. Silnik Reguł przechodzi przez każdy element sparsowanego przepływu pracy i tworzy równoważny potok danych DataFlow AI.

Działa w trzech warstwach, próbowanych po kolei:

1. Reguła deterministyczna. Dla większości powszechnych transformacji PowerCenter istnieje napisana ręcznie, dokładna reguła konwersji. Te reguły są przewidywalne i godne zaufania — to samo wejście zawsze daje to samo wyjście. Węzeł przekonwertowany w ten sposób jest oznaczony źródłem konwersji rule_engine.
2. Mapowanie ogólne. Jeśli nie ma dedykowanej reguły, ale typ transformacji jest nadal rozpoznawany, silnik tworzy ogólny węzeł przenoszący oryginalne ustawienia.
3. Asystent AI (LLM). Tylko gdy transformacja jest naprawdę nietypowa — a jej automatyczna pewność jest poniżej 0,60 — jest przekazywana do faktycznego modelu AI (Claude od Anthropic) w celu próby konwersji. Węzeł przekonwertowany w ten sposób jest oznaczony jako llm.

To oznaczenie ma znaczenie: gdy Marek później przegląda wynik, może natychmiast zobaczyć, jak powstał każdy węzeł — przez zaufaną regułę czy przez najlepsze przypuszczenie AI.

Tabela mapowania transformacja po transformacji

Oto serce konwersji — jak każdy typ transformacji PowerCenter staje się węzłem DataFlow. Każda konwersja zamienia wizualny „krok gotowania" w kawałek SQL (standardowy język, którym mówią bazy danych), co sprawia, że wynik jest szybki i przyjazny dla chmury.

Dla wf_SAP_Replika elementy, które napotyka silnik, są niemal wszystkie po zaufanej, wysokopewnej stronie tej tabeli — Source Qualifier i prosta Expression. Każdy z nich jest konwertowany przez regułę deterministyczną, oznaczony jako rule_engine, z pewnością na poziomie 0,85 lub wyższym. Same źródła i cele są konwertowane ze stałą pewnością 0,95.

Jak tłumaczone są formuły: Tłumacz Wyrażeń

Wewnątrz transformacji Expression lub Filter PowerCenter używa własnego małego języka formuł. DataFlow AI ma dedykowany komponent, Tłumacz Wyrażeń, który przepisuje te formuły na standardowy SQL. Rozumie zagnieżdżone wywołania funkcji, operatory i $$zmienne PowerCenter. Kilka ważnych przykładów:

$$zmienna z pliku parametrów staje się symbolem zastępczym parametru DataFlow, takim jak ${params.VAR}. Tam, gdzie tłumacz napotyka funkcję, której nie rozpoznaje, przepuszcza ją bez zmian, dodaje ostrzeżenie i obniża pewność, aby zaalarmować recenzenta.

Krok 5 — Punktacja pewności i bramka wydania 0,85

Każdy przekonwertowany węzeł otrzymuje wskaźnik pewności między 0 a 1 — uczciwą ocenę silnika, jak bardzo jest pewien, że konwersja jest poprawna. Filter osiąga 0,98 (bardzo pewny); transformacja Java osiąga 0,35 (bardzo niepewny). Ogólna pewność całego przepływu pracy to średnia wszystkich wyników węzłów, zaokrąglona do dwóch miejsc po przecinku.

Pewność to nie tylko liczba w raporcie — kontroluje ona, czy migracja może zakończyć się samodzielnie. To jest bramka wydania, a próg wynosi 0,85.

Po konwersji Centrum Migracji zbiera listę problemów blokujących. Zadanie jest zablokowane, jeśli prawdziwe jest którekolwiek z poniższych:

• Ogólna pewność jest poniżej 0,85 — „poniżej progu wydania 85%".
• Jakikolwiek pojedynczy obiekt został przekonwertowany z pewnością poniżej 0,80.
• Jakikolwiek obiekt otrzymał typ custom_transform lub niesie nierozwiązane issues.
• Strukturalna walidacja (opisana dalej) znalazła problem.

Jeśli ta lista blokująca jest pusta, zadanie zostaje oznaczone jako COMPLETED — przekonwertowało się czysto i jest gotowe do wdrożenia. Jeśli lista ma choć jedną pozycję, zadanie zostaje oznaczone jako FAILED, a komunikat błędu zadania mówi dokładnie, która bramka zadziałała. „Failed" nie oznacza tu, że coś jest zepsute — oznacza „człowiek musi na to spojrzeć, zanim trafi to dalej".

Dla wf_SAP_Replika każdy węzeł konwertuje się na poziomie 0,85 lub wyżej przez zaufane reguły, ogólna pewność komfortowo przekracza 0,85, a walidacja jest czysta. Zadanie ląduje na COMPLETED — jest jednym ze szczęśliwych 58%.

Krok 6 — Walidacja: sześć niezależnych kontroli bezpieczeństwa

Gdy zadanie było w stanie VALIDATING, na wygenerowanym potoku danych uruchomiły się dwie warstwy kontroli.

Kontrole strukturalne (Walidator Potoku)

Ta warstwa odczytuje wygenerowany YAML — plik tekstowy opisujący nowy potok danych — i sprawdza, czy jest poprawnie sformułowany:

1. Składnia YAML — plik musi się parsować, a jego najwyższy poziom musi być właściwą strukturą.
2. Wymagane klucze — potok danych musi mieć name i listę nodes.
3. Schemat węzła — każdy węzeł potrzebuje id i type; identyfikatory muszą być unikatowe; typ musi być jednym z source, transform, sink lub quality.
4. Odwołania krawędzi — każda strzałka musi wskazywać na węzły, które faktycznie istnieją.
5. Skanowanie bezpieczeństwa SQL — skanuje każdy fragment SQL pod kątem niebezpiecznych poleceń (DROP TABLE, TRUNCATE TABLE, ALTER TABLE, EXEC( i tak dalej) i zgłasza ostrzeżenie, jeśli któreś znajdzie.
6. Nazwy konektorów — każdy konektor musi być rozpoznawanym typem (Teradata, SAP HANA, Snowflake, Postgres, S3, Kafka i podobne).

Kontrole biznesowe (zestaw walidacji sześciu kontroli)

Gdy Marek później otwiera ekran Zestawu Walidacji i naciska uruchom, działa drugi, biznesowy zestaw sześciu kontroli zaliczenie/niezaliczenie:

Ogólny wynik jest pozytywny tylko wtedy, gdy zero kontroli kończy się niepowodzeniem. Dla wf_SAP_Replika wszystkie sześć przechodzi pomyślnie.

Krok 7 — Przegląd przekonwertowanego potoku danych

Nawet dla czystego, automatycznego zadania Marek wykonuje szybki przegląd. Na ekranie Konwersja AI Centrum Migracji otwiera raport migracji, który układa wszystko:

• Łączną liczbę obiektów w przepływie pracy oraz to, jak dzielą się na automatycznie przekonwertowane (pewność ≥ 0,8), wymagające przeglądu (0,5–0,8) i wymagające pracy ręcznej (poniżej 0,5).
• Rozkład pewności — ile węzłów wpadło do każdego przedziału, od „wysoki (90–100%)" w dół do „krytyczny (0–39%)".
• Pełną listę mapowań obiektów, każde pokazujące jego typ źródłowy z PowerCenter, jego nowy typ DataFlow, jego pewność i — co kluczowe — jego źródło konwersji (rule_engine lub llm).
• Wszelkie problemy walidacji i ostrzeżenia.
• Szacunek nakładu pracy w osobogodzinach: mniej więcej 0,25 godziny na każdy węzeł automatyczny, 1 godzina na przegląd każdego węzła wspomaganego przez AI, 2 godziny na węzeł w pełni ręczny, plus czas testowania i stałe 4 godziny testów integracyjnych.

Dla wf_SAP_Replika raport pokazuje wszystko jako automatycznie przekonwertowane przez silnik reguł. Jedyne prawdziwe działania następcze Marka to dwie drobne czynności porządkowe, które raport oznacza jako ręczne:

• Ścieżka pliku parametrów — wartości starego pliku .parm (nazwy baz danych, data ładowania) potrzebują nowego domu jako parametr przestrzeni roboczej DataFlow lub, w przypadku czegokolwiek tajnego, w Secret Manager.
• Alias połączenia — przepływ pracy odwoływał się do swoich baz danych przez stare nazwy aliasów PowerCenter; Marek zamiast tego wskazuje nowy potok danych na wcześniej zarejestrowane połączenia DataFlow.

Dla kontrastu, raport o złożonym przepływie pracy wf_E112 wyglądałby zupełnie inaczej — oznaczałby procedurę składowaną Sybase (getAddressChanges), procedurę składowaną MSSQL, wzorzec eksportu/reimportu jakości danych, tabelę buforową i wyrażenie o długości 2000 znaków, wszystkie wymagające dni pracy manualnej. Na tym polega różnica między 58% a 12%.

Krok 8 — Wdrożenie przekonwertowanego potoku danych

Gdy Marek jest zadowolony, pobiera wynik. Na ekranie raportu znajduje się przycisk Pobierz. Wybiera format YAML, a Centrum Migracji przekazuje mu plik o nazwie wf_SAP_Replika_converted.yaml.

Ten plik YAML jest nowym potokiem danych. Opisuje, w czystym, czytelnym dla człowieka tekście, całość:

pipeline:
  name: wf_SAP_Replika_l_BIURO_SPRZEDAZY_PLK
  description: Converted from Informatica PowerCenter
  schedule: manual
  sources:
    - id: src_sap_biuro_sprzedazy
      type: source
      connector: sap-hana
  transformations:
    - id: sql_select_passthrough
      type: transform
      depends_on: [src_sap_biuro_sprzedazy]
  targets:
    - id: sink_teradata_biuro
      type: sink
      connector: teradata
      depends_on: [sql_select_passthrough]
  quality_checks:
    - type: row_count_check
    - type: null_check
    - type: duplicate_check
    - type: schema_validation

Zauważ kontrole jakości na dole. Centrum Migracji dodaje je automatycznie: kontrola liczby wierszy, kontrola wartości pustych, kontrola duplikatów i kontrola schematu dla celu. Są to zabezpieczenia — gdy potok danych działa, potwierdzają, że dane naprawdę dotarły poprawnie. (Gdyby którykolwiek węzeł przekonwertował się z pewnością poniżej 0,80, dodana zostałaby również kontrola data_reconciliation, wymieniająca niepewne transformacje.)

Marek importuje ten YAML do przestrzeni roboczej DataFlow AI. Stamtąd przejmuje normalny przepływ pracy platformy: potok danych pojawia się w Studio Projektowym jako wizualny diagram pudełek i strzałek, gdzie może go zbadać, ustawić jego prawdziwy harmonogram (przepływ pracy działał co noc, więc nadaje mu harmonogram cron), wypełnić parametry i połączenia z Kroku 7 oraz zapisać. Zapisanie zatwierdza potok danych w Git, więc od pierwszego dnia jest wersjonowany — coś, czego stara konfiguracja PowerCenter nigdy nie miała.

Krok 9 — Weryfikacja wyników za pomocą uruchomienia równoległego

Marek nie wyłącza po prostu starego przepływu pracy i nie ufa nowemu. Program migracji Polkomtela nalega na uruchomienie równoległe.

Przez co najmniej dwa tygodnie obie wersje działają obok siebie każdej nocy:

• Oryginalny wf_SAP_Replika nadal działa w Informatica PowerCenter, dokładnie jak wcześniej.
• Nowy potok danych DataFlow AI działa na tych samych danych wejściowych.

Uruchomienie Równoległe i Walidacja Parzystości Danych DataFlow AI porównuje następnie oba wyniki w pięciu wymiarach:

1. Dokładna liczba wierszy — czy oba wyprodukowały tę samą liczbę wierszy?
2. Suma kontrolna — odcisk palca MD5/SHA-256 wszystkich danych, by wyłapać jakąkolwiek różnicę.
3. Próbkowanie kolumn — losowe 1000 wierszy porównanych kolumna po kolumnie.
4. Liczby wartości pustych — liczba pustych wartości na kolumnę musi się zgadzać.
5. Czas wykonania — nowy potok danych musi zakończyć się w czasie 2× dłuższym niż stary.

Narzędzie tworzy jasny raport zaliczenia/niezaliczenia. Bramka jakości Polkomtela dla prostej replikacji takiej jak ta to próg parzystości wyjścia 99,5%–100%. Gdy wf_SAP_Replika przekroczy ten próg przez pełne dwutygodniowe okno, Marek otrzymuje zatwierdzenie, całkowicie przełącza harmonogram na DataFlow AI, a stary przepływ pracy PowerCenter zostaje wycofany.

Cała podróż w skrócie

Oto kompletna wyprawa Marka, od starej furgonetki do nowej autostrady, w jednej liście:

1. Wyeksportuj wf_SAP_Replika z PowerCenter jako plik XML (plus jego plik .parm).
2. Prześlij plik XML do Kreatora Importu Centrum Migracji.
3. Centrum Migracji parsuje plik XML na neutralny wobec narzędzi opis.
4. Silnik Reguł konwertuje każdą transformację na węzeł SQL DataFlow — przez zaufaną regułę, mapowanie ogólne lub asystenta AI.
5. Każdy węzeł otrzymuje wskaźnik pewności; bramka wydania 0,85 decyduje o COMPLETED kontra FAILED.
6. Walidacja uruchamia sześć niezależnych kontroli bezpieczeństwa.
7. Marek przegląda raport migracji, sprawdzając źródło konwersji każdego węzła.
8. Pobiera przekonwertowany YAML, importuje go do przestrzeni roboczej, ustawia jego harmonogram, parametry i połączenia oraz wdraża go.
9. Dwutygodniowe uruchomienie równoległe dowodzi, że nowy potok danych dopasowuje się do starego wiersz po wierszu, po czym PowerCenter zostaje wycofany.

Pomnóż to przez ponad 500 przepływów pracy — większość z nich, jak wf_SAP_Replika, prostych i w 95% automatycznych — a Polkomtel wycofuje narzędzie kosztujące 1,2 mln–2 mln dolarów rocznie, przechodzi do chmury i kończy z w pełni udokumentowaną, kontrolowaną wersjami, nowoczesną platformą danych.

Najczęściej zadawane pytania

Czy dane przemieszczają się podczas migracji? Nie. Tylko instrukcje (przepis) przenoszą się z PowerCenter do DataFlow AI. Źródłowe bazy danych i hurtownia docelowa pozostają nietknięte. Nowy potok danych odczytuje i zapisuje te same systemy, co stary przepływ pracy.

Co się dzieje, jeśli nie można połączyć się z asystentem AI? Jeśli model AI jest niedostępny — zły klucz, limit zapytań, błąd API — pewność danego węzła jest wymuszana na 0,0 i jest on oznaczany jako wymagający ręcznego przeglądu. Zadanie nie przejdzie wtedy bramki 0,85. Jest to celowe: silnik nigdy nie udaje, że nieosiągalne AI „odniosło sukces".

Czy mogę ponownie uruchomić konwersję? Tak. Centrum Migracji obsługuje ponowną konwersję zadania. W obecnej konfiguracji ponownie waliduje to istniejący przekonwertowany potok danych i ponownie stosuje bramkę wydania, zamiast ponownie parsować oryginalny plik.

Dlaczego moje zadanie pokazało FAILED, gdy nic nie wygląda na zepsute? FAILED w Centrum Migracji oznacza „to wymaga człowieka" — bramka wydania zadziałała. Komunikat błędu zadania wymienia dokładną bramkę (niska ogólna pewność, obiekt o niskiej pewności, custom_transform lub problem walidacji), więc wiesz dokładnie, na co spojrzeć.

Co z procedurami składowanymi? Treść procedury składowanej nie jest migrowana. Centrum Migracji potrafi wykryć, że procedura jest wywoływana, i utworzyć węzeł wywołania, ale sama procedura albo pozostaje w bazie danych źródłowej, albo musi zostać przepisana ręcznie — to znana porcja pracy manualnej.