12 munkanap alatt költöztette adatplatformját a Kilo ügynökökkel

Három hónap helyett 12 munkanap

A migráció az adatokat beérkeztető kapcsolatokat, az azokat feldolgozó kódot, az üzleti eszközökbe visszaküldött szinkronizációkat és az üzletiintelligencia-irányítópultokat is érintette. A Kilo feladata az volt, hogy mindezt az Anaconda adatplatformjába helyezze át úgy, hogy közben kezelje a függőségeket, újraépítse a jogosultságokat és integrációkat, fenntartsa a működést, valamint ellenőrizze, hogy az új környezet ugyanazokat az eredményeket adja.

A Kilo közlése szerint a korábbi két migráció összesen több mint hat hónapig tartott. Hasonló technológiai környezetben ügynökök nélkül körülbelül három hónapra számítottak volna. A terv jóváhagyásától a befejezésig végül 12 munkanap telt el. A 2026. szeptember 24-i beszámoló szerint a projekt eredetileg tíznapos ütemezéssel készült, ezért az ütemterv nem a tényleges időtartamot rögzítette.

Az ügynök először a migráció tervét készítette el

A Kilo mérnöke az ügynöknek először az Anaconda Confluence-ben tárolt dokumentációját adta át az Atlassian MCP-n keresztül, majd arra kérte, hogy vizsgálja meg a kapcsolódó rendszereket. A Kilo oldalán egy olyan tudásbázishoz kapott hozzáférést, amely Slack-beszélgetésekből, GitHub-tevékenységből, megbeszélések átirataiból és korábbi ügynökmenetekből állt.

Az ügynök ebből elkészítette a migrációs terv első változatát, a függőségekkel, az ellenőrzésekkel és a visszaállítási eljárásokkal együtt. A dokumentumon nagyjából 48 órát dolgoztak. Tartalmazta a kiinduló, köztes és végső architektúra ábráit, a párhuzamosan végezhető feladatokat, a más csapatoktól szükséges döntéseket és jóváhagyásokat, a végrehajtási lépéseket, a titkok létrehozását vagy cseréjét, továbbá az érintett táblákat, mezőket és a downstream rendszerek által várt kimeneteket.

Az architektúra négy ábráját az ügynök készítette Excalidrawban. A kezdeti állapotban hat adatbetöltési útvonal vezetett a Snowflake-be, középen a kilocode-dbt projekt működött, a kimeneti oldalon pedig többek között az Omni, a Metabase, a Hightouch reverse ETL és az Airbyte továbbította az adatokat. Az átmeneti fázisban a backend, a PostHog és a Stripe adatai KILO_TRANSITION sémákba kerültek, miközben egy auditpillanatkép megőrizte az eredeti sémákat.

Eszközök, ellenőrzések és böngészőautomatizálás

A tervezési dokumentumból Jira-feladatok és ismételhető runbookok, vagyis részletes eljárásleírások készültek. Az Omni irányítópultjainak migrációját például egyszer végrehajtották az ügynökkel, majd az ügynök leírta a pontos lépéseket. A hibákból azonnal módosították a runbookot, így az adott munkamenet tanulsága a későbbi végrehajtásokban is megmaradt. A művelethez az ellenőrzés módját is hozzáadták.

Az Omni meglévő MCP-je csak olvasni tudta az irányítópultokat, ezért a Kilo kibővített egy saját írási MCP-t. Az eszköz friss exportot követelt meg az éles forrásból, elutasította az elavult vagy módosított pillanatképeket, majd ellenőrizte az importált irányítópult szerkezetét és lekérdezéseit. A heti aktív felhasználókat mutató irányítópult 41 csempéjét a módosítás után sikerült ellenőrizni, a publikálást a mérnök hagyta jóvá.

Azokat a lépéseket, amelyekhez a rendelkezésre álló API-k nem voltak elegendők, böngészőügynök hajtotta végre. A Hightouch migrációja teljes egészében így zajlott. A Meta és a Bing Ads adatbetöltési kapcsolatainál az ügynök megkereste az új tokenek létrehozásának helyét és lépéseit. A Kilo emellett egy Migration Assistant nevű egyedi módot is készített, amely segített kiválasztani a megfelelő eszközt és környezetet az egyes műveletekhez.