Moderné spoločnosti často čelia potrebe migrovať svoje informačné systémy. Tomuto postupu však musí predchádzať starostlivá príprava, keďže na ceste je veľa prekážok.

Dôvodov na začatie prechodu na nový informačný systém (IS) môže byť veľa, vrátane znižovania rizík spojených s prevádzkou zastaraných platforiem, zosúlaďovania informačných systémov na medzinárodné štandardy a zvyšovania efektívnosti podnikových procesov. Ale bez ohľadu na to, akej úlohe spoločnosť čelí, prechod z jednej IP na druhú musí byť starostlivo naplánovaný a pripravený.

Problémy s migráciou

Pokiaľ ide o migráciu transakčných systémov ako ERP, fakturácia, spracovanie alebo core banking, prechod na nový systém je veľmi problematický. Faktom je, že IT profesionáli musia zabezpečiť presnú migráciu veľkých objemov dát, zachovať paralelnú prevádzku starého a nového systému pre zosúladenie a analýzu výsledkov.

Mal som napríklad projektové skúsenosti v jednej z najväčších bánk, kde prebiehal presun transakčného systému z už nepodporovanej platformy Informix na platformu Oracle. Zároveň bolo potrebné vykonať dôkladnú analýzu obchodných procesov, opakovane prenášať údaje zo starého systému do nového a kontrolovať konzistentnosť výsledkov nového a starého systému s prihliadnutím na trvanie procesné predpisy. Preto bolo obdobie migrácie 14 mesiacov. Niekedy môže paralelná prevádzka dvoch systémov pokračovať dlhší čas, ale aj keď je obmedzená na niekoľko mesiacov, zabezpečenie prevádzky nového IS si vyžaduje pridelenie dodatočného výpočtového výkonu a značného času zamestnancov podniku na súčasné vykonávanie úloh v dvoch systémoch. .

Od systému oddelení až po podnikovú úroveň

Aktualizácia IP sa často vyskytuje v rámci globalizácie a centralizácie. To vám umožňuje výrazne znížiť náklady na podporu a aktualizáciu softvérových systémov. Udržiavať jednotnú platformu, ktorá slúži všetkým zamestnancom, je skutočne oveľa jednoduchšie ako udržiavať samostatné nástroje pre každé oddelenie. Napríklad úspešná migrácia systému účtovania zásob vám umožňuje preniesť niekoľko tisíc oddelení veľkej organizácie na jednu platformu a výrazne znížiť náklady na IT. Treba však pripomenúť, že väčšina príprav v tomto prípade pripadá na koordináciu údajov v rôznych formátoch a reprezentáciách, vývoj nových predpisov a konštrukciu nových modelov interakcie zamestnancov.

Ďalším dôležitým aspektom sú integračné rozhrania s inými podnikovými informačnými systémami, najmä vlastnými a špecifickými. Problémy s nimi spojené nemusia byť v prvej fáze také viditeľné, ale sú identifikované pri vytváraní interakcie medzi rôznymi oddeleniami a celkovým systémom. A ak pre starý systém boli takéto rozhrania už implementované programovo alebo organizačne, potom pre nový systém môže byť potrebné ich vyvinúť nanovo.

Treba mať na pamäti, že myšlienky na rozšírenie funkcionality systému môžu prísť už počas realizácie projektu, podobne ako chuť do jedla počas jedla. To znamená, že bude potrebná celá séria dodatočných prác.

Akčný plán

Skúsenosti z projektových aktivít v oblasti migrácie systému ukazujú, že každý takýto projekt si vyžaduje starostlivú prípravu a musí byť sprevádzaný individuálnym plánom. Avšak bez ohľadu na typ migrovaných systémov, softvér, objemy databáz atď., všeobecná schéma vyzerá takmer identicky.

V prvej fáze je potrebné vykonať podrobný audit, zistiť všetky požiadavky na spôsob fungovania nového systému, pohovoriť so všetkými kľúčovými používateľmi. Je dôležité pochopiť, o akých objemoch dát a o akej záťaži hovoríme, až potom budú odborníci schopní navrhnúť správnu stratégiu migrácie.

Aj samotné postupy musia byť dôkladne premyslené a musia obsahovať také dôležité prvky, ako sú pravidlá pre prístup používateľov k systémom počas migrácie, postupy návratu do predchádzajúceho stavu v prípade zlyhania a interakcia rôznych špecialistov zapojených do týchto procesov. .

Po dohode so zákazníkom sa zvyčajne vypracuje podrobný plán, ktorý zahŕňa niekoľko etáp, a to: kopírovanie dát, overenie, paralelnú prevádzku dvoch systémov a úplný prechod na novú platformu. Pri profesionálne organizovanej migrácii systému je podľa mňa hlavná plynulosť procesu pre používateľov, ktorí môžu postupne bez stresu začať pracovať v novom automatizovanom systéme.

Ani starostlivá príprava vás však vždy nezachráni pred podhodnotením nákladov na pracovnú silu pri presune používateľov na „nové koľajnice“. Tento proces zahŕňa ako vzdelávanie zamestnancov spoločnosti, tak aj ich podporu v období adaptácie na nový systém.

Leif Poulsen pre InTech

Systémy na automatizáciu výroby a zber informácií o výrobných procesoch majú relatívne krátku životnosť. Často sa musia modernizovať alebo vymeniť skôr, ako procesné zariadenie dosiahne koniec svojej životnosti. Pre mnohé spoločnosti je riadenie výmeny alebo modernizácie takýchto automatizačných systémov bez zastavenia výroby skutočnou výzvou. Preto sa objektívna potreba modernizácie alebo výmeny ignoruje, kým sa niečo nestane. Tento článok je o tom, ako môžete úspešne splniť túto úlohu prostredníctvom starostlivého plánovania a organizácie.

Za potrebou modernizácie a výmeny systémov priemyselnej automatizácie a priemyselných IT systémov stoja dva hlavné faktory: technická degradácia týchto systémov, ako aj zmeny v požiadavkách obchodných procesov, ktoré tieto systémy podporujú.

Spoľahlivosť technických systémov sa časom zníži, ak spoločnosti ignorujú potrebu modernizácie operačných systémov, databáz a aplikačného softvéru. Zodpovedajúcim spôsobom sa zvyšuje prevádzkové riziko zlyhania zariadenia.

Prostredníctvom starostlivého plánovania je možné udržať prevádzkové riziko na prijateľnej úrovni a zároveň chrániť investície a minimalizovať náklady na životný cyklus. Pre typický automatizačný alebo IT systém ide len 20-40% investície do nákupu systému. Zvyšných 60 – 80 % ide na udržanie jeho vysokej dostupnosti a prispôsobenie sa pravidelne sa meniacim požiadavkám.

Okrem hodnotenia činností potrebných na zabránenie technickej degradácii je potrebné zvážiť nové výzvy, ako aj potenciálne obchodné príležitosti. Podnikateľské prostredie sa neustále mení a vždy treba zvážiť všetky príležitosti na zlepšenie existujúcich alebo zavedenie nových technológií. Typické obchodné príležitosti, ktoré môžu viesť k migrácii vysokonákladových automatizačných systémov, sú rýchlosť na trh, konkurencieschopnosť, rast, kvalita a súlad s predpismi.

Dlhodobý plán migrácie

Vypracovanie dlhodobého plánu migrácie systému umožňuje spoločnostiam udržiavať systémové operačné riziká na prijateľnej úrovni. Okrem toho zabezpečuje riadenie rizík a včasnú podporu obchodných cieľov. Plán migrácie musí brať do úvahy obmedzenia, ako sú „najlepšie výrobné postupy“, funkčnosť technológie a nevyhnutné prestoje výroby.

Vo všeobecnosti je prístup k dlhodobému plánovaniu znázornený na obr. Vypracuje sa plán migrácie, aby sa určilo, kde chce byť spoločnosť o päť rokov, aké kroky je potrebné podniknúť, aby sa tam dostala, a či sú k dispozícii zdroje potrebné na to, aby sa tam dostala. Tento prístup je založený na princípoch architektonického dizajnu načrtnutých v štandarde TOGAF, ktorý je široko používaný pri vývoji systémovej architektúry pre priemyselné podniky.

Obrázok 1. Všeobecný prístup k tvorbe dlhodobého plánu migrácie.

Je potrebné rozlišovať medzi existujúcou architektúrou a cieľovou, želanou. Rozdiel medzi nimi odráža rozdiel medzi súčasnou pozíciou firmy a pozíciou, ktorú chce obsadiť v budúcnosti. Plán migrácie mapuje cestu od existujúcej architektúry k cieľovej architektúre – možno cez niekoľko prechodných fáz.

Každú architektúru možno opísať ako sériu „vrstiev“, ktoré premosťujú priepasť medzi podnikaním a technológiou – ako je znázornené na obrázku 1. 1. Pozornosť treba venovať nasledujúcim „vrstvám“:

• Obchodné ciele je súčasťou celkového úsilia o plánovanie stratégie. Umožňujú vám vybrať si správny smer procesu.
• Obchodný model poskytuje kontext, v ktorom sa chápu výrobné a obchodné procesy. Zvyčajne obsahuje popis materiálových tokov a procesov na vysokej úrovni.
• Popis výrobné a obchodné procesy je dôležitá pre úspešnú aplikáciu technológií a správne posúdenie ich hodnoty z obchodného hľadiska.
• Informácie, údaje a dokumenty dôležité pre prepojenie procesov a aplikácií. Dôležitá je najmä interoperabilita a riadenie informačných tokov medzi aplikáciami.
• Popisy aplikácie umožňujú formulovať požiadavky na vysokej úrovni a definovať rozhrania.
• Definícia infraštruktúry, výpočtovej techniky a siete požiadavky (hardvér, odolnosť voči chybám, výkon).
• Za predpokladu služby definovať požiadavky na zabezpečenie efektívneho operatívneho riadenia a podpory rozhodovania.

Vypracovanie migračného plánu

Vypracovanie plánu migrácie pre celú organizáciu alebo dokonca jedno výrobné miesto môže byť skutočne zložitou úlohou, na ktorej sa bude podieľať veľa ľudí. Odporúča sa rozdeliť proces vývoja do niekoľkých etáp, ktoré sú popísané nižšie.

Časť II

1. fáza: Mobilizácia

Základné ciele:

• dosiahnuť spoločné chápanie úloh a cieľov
• mobilizovať organizáciu, v ktorej sa projekt plánuje
• podrobne plán popíšte míľniky a výsledky fáz projektu
• zbierať všetky potrebné/dostupné informácie
• poskytnúť správne pochopenie pojmov, postupov a teórie

• plánované stretnutia
• workshop venovaný začiatku projektu

Výsledky:

• podrobný plán konzultácií
• spoločné ciele
• prehľad procesu

Fáza 2: Analýza

Cieľmi fázy analýzy sú:

• analýza obchodných a výrobných procesov s cieľom:

Posúdiť pripravenosť personálu obsluhujúceho IT a automatizačné systémy

Pochopte potreby údajov a funkcií pre budúcu architektúru

Identifikujte kľúčové výhody budúcej architektúry na stanovenie cieľov a implementáciu obchodného prípadu

• analýza existujúcej architektúry

Stanovenie existujúcich výrobných procesov v ich prepojení s automatizačnými systémami, zber dát, systémy riadenia výroby

Identifikácia existujúcich podnikových procesov a ich prepojenia so systémami automatizácie výroby

Identifikujte existujúce aplikácie, údaje, logickú a fyzickú infraštruktúru a služby technickej podpory

Počas tejto fázy sa vykonávajú tieto činnosti:

• semináre a diskusie o rôznych procesoch
• návštevy stránok s cieľom získať kontextové informácie
• semináre a diskusie o existujúcich systémoch
• posudzovanie služieb s cieľom určiť ich vyspelosť a súlad s regulačnými požiadavkami

Výsledky:

• identifikáciu existujúcej infraštruktúry
• analytická dokumentácia
• zoznam nápadov na výzvy a príležitosti novej architektúry zoznam nápadov na výzvy a príležitosti novej architektúry

3. fáza: Cieľ

Účelom tejto fázy je identifikovať a opísať potreby formulované počas fázy analýzy.

Riešenie alebo cieľová architektúra bude popisovať:

• budúce obchodné procesy a funkčnosť
• cieľové typy aplikácií s ich funkčnosťou, používateľmi, informáciami a rozhraniami
• potreby infraštruktúry a revidované normy podpory

Počas tejto fázy sa vykonávajú tieto činnosti:

• semináre a diskusie o zlepšovaní procesov
• workshopy a diskusie o zlepšovaní architektúry

Výsledky:

• budúca architektúra (prezentácia)
• Stručný popis typov aplikácií

Fáza 4: Odôvodnenie

Účelom fázy zdôvodňovania je poskytnúť počiatočný obchodný prípad založený na hrubých odhadoch nákladov a prínosov projektu.

Priepasť medzi existujúcou a želanou situáciou zvyčajne vedie k vzniku množstva myšlienok. Zdôvodnenie nápadov vám umožní rozlíšiť „nevyhnutné“ od „žiaduce“ a následne nápady prezentovať a rozvíjať vrcholovému manažmentu.

Počas tejto fázy sa vykonávajú tieto činnosti:

• hrubý odhad nákladov a prínosov
• prvá verzia prezentácie

Výsledky:

• spoločné ciele
• uprednostňovanie podnikateľských nápadov
• posúdenie požadovaných zdrojov

Fáza 5: Plán

Účelom tejto fázy je naplánovať projekt na základe priorít, zdrojov a závislostí:

• plánovanie postupnosti realizácie etáp konsolidovaného projektu
• poskytovanie zdrojov a kompetencií potrebných pre ďalšie kroky
• iniciovanie aktivít projektového manažmentu
• dokončenie poradenstva a prenos výsledkov všetkých etáp k zákazníkovi

Počas tejto fázy sa vykonávajú tieto činnosti:

• vypracovanie plánu implementácie
• vypracovanie investičného plánu
• posúdenie rizík

Výsledky:

• implementačný plán
• posúdenie pracovného zaťaženia personálu zapojeného do projektu
• hodnotenie rizika projektu
• investičný plán (ako prvé priblíženie)
• finálna verzia prezentácie projektu

Prípadová štúdia

Nasledujúci príklad ilustruje aplikáciu opísaného prístupu v reálnych podmienkach. Aby boli dodržané podmienky dôvernosti, je v popise zachovaná anonymita. Hovoríme o pomerne veľkom podniku, ktorý vyrába účinné látky pre farmaceutické výrobky. Výrobné zariadenia boli uvedené do prevádzky pred viac ako 20 rokmi a hoci odvtedy prebehla určitá modernizácia, množstvo zastaraných systémov si vyžaduje výmenu. Systémy automatizácie budov a DCS sú na prvom mieste, keďže sú založené na zastaraných technológiách, ktoré sú náročné na údržbu. Okrem toho sa výroba musí prispôsobiť novým obchodným požiadavkám vrátane ukončenia výroby niektorých produktov a uvedenia iných na trh. Vo všeobecnosti je potrebné pracovať na pláne migrácie, ktorý pokrýva technické aj obchodné požiadavky.

Najprv musíte vytvoriť hlavný zoznam zariadení, ktoré sa v súčasnosti v podniku používajú. Tieto informácie sú často „ukryté“ v rôznych dokumentoch (a v pamätiach zamestnancov). Musí sa extrahovať a vizualizovať, aby sa stal základom pre plánovanie migrácie. Na tento účel zvyčajne vytvárame schému modulov procesu zobrazujúcu hlavné pohyby zariadení a surovín v každej výrobnej jednotke. Ako samostatné vrstvy „navrchu“ hardvéru ukazujeme, ktoré systémy podporujú ktorý hardvér.

Príklad je znázornený na obr. 2. Údaje o nainštalovaných systémoch sú tiež obsiahnuté v systémovom úložisku (alebo jednoducho v súboroch Excel) a môžu byť použité na ďalšiu analýzu a plánovanie.

Obrázok 2. „Vrstva“ automatizácie vám umožňuje vyhodnotiť existujúce systémy

Pred diskusiou o pláne migrácie je potrebné identifikovať hlavné obchodné dôvody zmien vo výrobe. V tomto prípade vedenie identifikovalo tieto motívy:

1. Dôsledné a bezchybné dodržiavanie regulačných požiadaviek

2. Minimálny čas potrebný na vstup na trh, flexibilita

3. Úspech, konkurencieschopnosť, prevádzková dokonalosť

4. Nekompromisná kvalita

5. Rast objemu výroby

Tieto ciele je potrebné pretaviť do špecifickejších úloh, ktorých plnenie je možné kvantifikovať.

Ďalej musíme zistiť, ako dobre existujúce systémy podporujú súčasné a budúce obchodné procesy. Na tento účel používame štandardný referenčný model (na základe série noriem ANSI/ISA-95). Zahŕňa 19 obchodných procesov na vysokej úrovni, podrobne rozpracovaných do takej miery, že vám to umožní vidieť slabé miesta v ich praktickej implementácii a potrebu zmeny v záujme efektívneho podnikania.

Okrem toho musíme zhodnotiť aj technické možnosti existujúcich systémov na podporu obchodných procesov v budúcnosti. Deje sa to systematicky pomocou vyššie popísaných informácií zo systémového úložiska. Pre každý systém, pre ktorý sú informácie v úložisku (v našom prípade asi 70 systémov), je potrebné posúdiť tieto aspekty:

• Stav zariadenia (história porúch, stredný čas medzi poruchami, vek zariadenia, dostupnosť náhradných dielov)
• Stav softvéru (podpora dodávateľa, dostupnosť dokumentácie, personál s potrebnými kompetenciami)
• Možnosti obnovy systému (redundancia, priemerná životnosť pred opravou)
• Hodnotenie vplyvu na podnikanie (poskytovanie informácií, chyby údajov, nedostupnosť)
• Orientačné ukazovatele (spoľahlivosť systému, kritickosť systému atď.)

V technickom hodnotení sa zistila potreba modernizácie a výmeny niekoľkých systémov:

• Systémy riadenia procesov sú založené na konvenčnom, zastaranom DCS a mnohých rôznych PLC, z ktorých niektoré sú už „zrelé“ na výmenu.
• Systém automatizácie budov je založený na novšej platforme, ale vyžaduje aj modernizáciu, aby spĺňal nové požiadavky.
• Modernizáciu alebo dokonca výmenu vyžaduje aj množstvo sekundárnych systémov.
• Infraštruktúra slúžiaca všetkým systémom vyžaduje lepšiu segmentáciu a ochranu, aby splnila súčasné bezpečnostné požiadavky.

Časť III

Po analýze obchodných cieľov do budúcnosti sa ukázalo, že žiadny z existujúcich systémov plne nespĺňa budúce potreby. Toto chápanie dalo podnet na vznik množstva nápadov týkajúcich sa zavádzania nových technológií, ako aj systému realizácie výroby. Ako výsledok analýzy bolo navrhnutých 16 rôznych projektov, ktoré, ak budú dôsledne implementované, pomôžu spoločnosti splniť budúce technické a obchodné požiadavky.

Hodnotí sa obsah technickej práce a náklady na každý projekt; Ku každému projektu je pripravené krátke jednostranové zhrnutie, ktoré môže vedenie prediskutovať. (Pozri obrázok 3).

Ryža. 3. Jednostranový popis potenciálneho projektu migrácie

Pri výbere prioritných projektov sa posudzujú potenciálne výsledky každého z nich. Výsledky sa posudzujú z hľadiska obchodných cieľov, ako aj spoľahlivosti systému riadenia procesov.

Zvyčajne budete musieť vyhodnotiť viaceré scenáre implementácie, aby ste odhadli celkové požiadavky na zdroje a financovanie pre každý plán (obrázok 7). Jedným z hlavných obmedzení, ktoré je potrebné zvážiť, sú okná vo výrobnom procese, počas ktorého je možné systémy vymeniť alebo upraviť. Spravidla sa tieto „okná“ vyskytujú cez víkendy - a to je vážna prekážka.

Ryža. 7. Konsolidovaný prehľad harmonogramu migrácie

Keďže na výmenu systémov a ich nastavenie je vždy málo času, príprava musí byť veľmi dôkladná. Všetko treba do detailov naplánovať. Dôležitým aspektom plánovania je testovanie implementovaných systémov.

V prípade, ktorý popisujeme, bola realizácia dlhodobého migračného plánu realizovaná v šiestich rôznych prúdoch, pozri obr. 8.

Ryža. 8. Organizovanie migračných projektov v šiestich rôznych prúdoch

Súčasťou prípravy je dôkladné posúdenie a prevencia rizík projektu. Na obr. Obrázok 9 ukazuje typické riziká spojené s projektmi migrácie.

Ryža. 9. Hodnotenie typických rizík migračných projektov

Procesy podpory podnikania

Riadenie životného cyklu a plánovanie dlhodobého plánovania migrácie opísané v tomto článku sa riadia obchodnými potrebami. Zahŕňa posúdenie súčasných a budúcich obchodných cieľov, ako aj dôkladnú analýzu toho, ako budú technické systémy udržiavané alebo nahradené, aby tieto ciele čo najlepšie podporovali. Prístup je založený na princípoch TOGAF, ktoré zabezpečujú postupnú realizáciu projektov v závislosti od dostupnosti rozpočtov a kvalifikovaného personálu. Hodnotenie súčasných a budúcich systémových architektúr je kľúčovým prvkom pri určovaní budúcich projektov migrácie. Nakoniec je potrebné dodržiavať princípy riadenia organizačných zmien, ktoré zabezpečia včasné zapojenie kľúčových zainteresovaných strán projektu, čo je také dôležité pre úspech migračných projektov. Účinnosť tohto prístupu bola opakovane preukázaná v praxi.

Leif Poulsen) ( ), popredný špecialista na automatizáciu a IT v NNE Pharmaplan. Je držiteľom magisterského titulu z procesného manažmentu. V NNE Pharmaplan je Poulsen zodpovedný za vývoj technológií, metód a kompetencií v oblasti priemyselnej automatizácie a IT a pôsobí ako senior business konzultant.

Posledná aktualizácia: 31. 10. 2015

Často nastáva situácia, keď sa model zmení. Napríklad sme sa rozhodli do nej zaviesť nové vlastnosti. Ale zároveň už máme existujúcu databázu, ktorá obsahuje nejaké údaje. A aby sme aktualizovali databázu bez straty, ASP.NET MVC nám ponúka taký mechanizmus ako migrácie. Napríklad máme jednoduchý používateľský model:

Public class User ( public int Id ( get; set; ) public string Name ( get; set; ) )

Podľa toho existuje dátový kontext, prostredníctvom ktorého pracujeme s databázou:

Používatelia (get;set;))

A povedzme, že máme všetku infraštruktúru na prácu s týmto modelom – pohľady, radiče a v databáze už máme niekoľko objektov tohto modelu. V určitom okamihu sme sa však rozhodli zmeniť základňu modelu aplikácie. Do modelu používateľa sme napríklad pridali ďalšie pole:

Public class User ( public int Id ( get; set; ) public string Name ( get; set; ) public int Age ( get; set; ) )

Okrem toho sme sa rozhodli pridať ešte jeden model, napr.

Verejná trieda Spoločnosť ( public int Id ( get; set; ) public string Name ( get; set; ) )

Náš dátový kontext sa teda už mení takto:

Verejná trieda UserContext: DbContext ( public UserContext() : base("DefaultConnection") ( ) public DbSet Používatelia ( get; set; ) public DbSet Spoločnosti ( získať; nastaviť; ) )

Do pohľadov pre model používateľa môžeme pridať ďalšie pole pre vlastnosť Age, môžeme vytvoriť ovládač a pohľady pre nový model, ale keď sa pokúsime pridať nový objekt do databázy, zobrazí sa chyba:

Kontext údajov sa zmenil a teraz musíme migrovať zo starej schémy databázy na novú. A najprv nájdite okno Package Manager Console v spodnej časti Visual Studia, zadajte doň príkaz: enable-migrations a stlačte Enter:

Po spustení tohto príkazu Visual Studio sa v projekte vytvorí priečinok Migrations, kde nájdete súbor Configuration.cs. Tento súbor obsahuje deklaráciu triedy Configuration s rovnakým názvom, ktorá nastavuje konfiguračné nastavenia:

Namespace MigrationApp.Migrations ( pomocou System; pomocou System.Data.Entity; pomocou System.Data.Entity.Migrations; pomocou System.Linq; interná zapečatená konfigurácia triedy: DbMigrationsConfiguration ( public Configuration() ( AutomaticMigrationsEnabled = false; ContextKey = "MigrationApp.Models.UserContext"; ) chránené prepísanie void Seed(MigrationApp.Models.UserContext context) ( ) ) )

V metóde Seed môžete inicializovať databázu so semennými údajmi. Teraz musíme vytvoriť samotnú migráciu. Tam v konzole správcu balíkov zadajte príkaz:

PM Add-Migration "MigrateDB"

Visual Studio potom automaticky vygeneruje migračnú triedu:

Namespace MigrationApp.Migrations ( using System; using System.Data.Entity.Migrations; verejná čiastočná trieda MigrateDB: DbMigration ( public override void Up() ( CreateTable("dbo.Companies"), c => new ( Id = c.Int( možnosť null: false, identity: true), Name = c.String(), )).PrimaryKey(t => t.Id) AddColumn("dbo.Users", "Vek", c => c.Int(s možnosťou null). : false)); verejné prepísanie void Down() ( DropColumn("dbo.Users", "Vek"); DropTable("dbo.Companies"); ) ) )

V metóde Up sa volaním metódy CreateTable vytvorí tabuľka "dbo.Companies" a vykoná sa jej konfigurácia: vytváranie stĺpcov, nastavenie kľúčov. A do existujúcej tabuľky sa pridá aj nový stĺpec Vek. Metóda Down odstráni stĺpec a tabuľku v prípade, že existujú. V skutočnosti sú tieto metódy ekvivalentné výrazu ALTER v SQL, ktorý mení štruktúru databázy a jej tabuliek.

A nakoniec, aby sme vykonali migráciu, použijeme túto triedu zadaním príkazu do rovnakej konzoly:

Aktualizácia PM databázy

Potom, ak sa pozrieme na zloženie databázy, uvidíme, že v nej boli aplikované zmeny v súlade s vykonanou migráciou:

Migrácia je teda hotová a už môžeme použiť aktualizované modely a dátový kontext.

V tomto článku by sme chceli systematizovať naše skúsenosti s migráciou dát vo veľkých podnikových projektoch súvisiacich s prechodom zákazníkov na prácu v konfiguráciách 1C:Enterprise 8.

Zároveň bude hlavný dôraz v článku kladený predovšetkým na technologickú zložku migračného procesu. Postihnutá je aj organizačná zložka, ale v menšej miere.

Pojmy a definície

Migrácia dát sa zvyčajne chápe ako finálna postupnosť prác, projekt zameraný na jednorazový hromadný presun dát zo zdrojových systémov (historických systémov) do cieľového systému. Zároveň sa prestáva využívať tieto údaje v zdrojových systémoch.

Migráciu údajov treba odlíšiť od integrácie údajov. Integrácia je na rozdiel od migrácie trvalou súčasťou IT architektúry a je zodpovedná za tok dát medzi rôznymi systémami a dátovými skladmi – a je skôr procesom než projektovou činnosťou.

Schéma migrácie vo všeobecnosti vyzerá takto:

Ryža. 1

Historické systémy- databázy spoločnosti Zákazníka, ktoré sa plánujú úplne alebo čiastočne nahradiť pri implementácii nového systému.

Systém prijímača- cieľový systém, ľubovoľná konfigurácia „1C:Enterprise 8“.

Počiatočné údaje- údaje stiahnuté z historických systémov do vlastného formátu súboru xls. V tomto prípade sa formát xls javí ako jeden z najpohodlnejších, pretože možnosť nahrávania do súboru xls je prítomná v mnohých účtovných systémoch „predchádzajúcich generácií“.

Za modernú alternatívu transportu je možné považovať formát súboru xml.

Existujú aj možnosti použitia prechodnej databázy.

Transformácia, konverzia- proces premeny zdrojových údajov na údaje pre načítanie. Transformácia údajov prebieha v súlade so šablónami načítania. Výsledkom transformácie sú dáta, ktoré sa majú načítať.

Stiahnite si dáta- údaje určené na načítanie do prijímacieho systému. Tento článok, ako aj zdrojové údaje, zvažuje formát xls.

Dátové šablóny na načítanie- popis tabuliek údajov, ktoré sa majú načítať do cieľového systému.

Etapy migrácie

Pozrime sa na proces prípravy a realizácie migrácie krok za krokom.

Organizačné fázy migrácie zahŕňajú nasledujúce body:

· Definovanie migračnej stratégie. V tejto fáze sa Dodávateľ a Objednávateľ dohodnú na technológii vykonávania migračných prác;

· Určenie zloženia pracovnej skupiny pre migráciu. Pracovná skupina by mala zahŕňať špecialistov z radov Dodávateľa aj Objednávateľa, ktorí sú dostatočne oboznámení s prevádzkou historických systémov (na strane Objednávateľa) a cieľového systému (na strane Dodávateľa);

· Predbežný plán migrácie. Plán migrácie sa bude v priebehu projektu niekoľkokrát upravovať;

· Termíny sťahovania dát z historických systémov, objemy dát. Obdobia prerušenia údajov pre migrácie, dátumy testovania a konečné migrácie. Tieto informácie možno pripísať plánu migrácie;

· Zloženie údajov, ktoré sa majú migrovať. Referenčné údaje, klasifikátory, údaje o transakciách, zostatky, obrat atď.;

· Problémy kontroly kvality, správnosti a integrity údajov počas procesu migrácie a na konci;

· Problémy s návratom do predchádzajúceho stavu v prípade porúch.

Pozrime sa bližšie na technologické fázy migrácie.

Ryža. 2

1. Príprava šablón na načítanie údajov

Šablóna načítania údajov obsahuje technické popisy tabuliek údajov, ktoré sa majú načítať, algoritmy a pravidlá načítania pre aktuálnu šablónu.

Každá šablóna sa vo všeobecnosti zameriava na jednu alebo viac súvisiacich tabuliek v cieľovom cieľovom systéme.

V šablóne sa uvádza:

· Popis všetkých polí dátového súboru xls na stiahnutie, vrátane:

o Názov poľa

o Indikátor, že pole musí byť vyplnené

o Príklad vyplnenia poľa

o Poznámka

· Popis pravidiel pre načítanie cieľovej systémovej tabuľky na základe údajov, ktoré sa majú načítať (poradie v prípade viacerých súvisiacich tabuliek, vyhľadávacie algoritmy pre kľúčové polia atď.)

· Opis priameho vyplnenia polí cieľových systémových tabuliek, ak je k dispozícii niečo iné ako prenos údajov „jedna k jednej“ z dátového súboru na načítanie. Relevantné napríklad pre referenčné polia.

Počas prác v tejto fáze musí zhotoviteľ pripraviť aj načítač dátových súborov na načítanie. Pri práci so súbormi xls nie je táto úloha obzvlášť náročná.

2.Identifikácia zdrojov údajov

Táto etapa môže začať spolu s predchádzajúcou etapou „1. Pripravujú sa šablóny na načítanie údajov."

V tejto fáze špecialisti zákazníka určia, z ktorých systémov a aké údaje je možné stiahnuť. Mali by ste tiež určiť, aké údaje Možno môže byť potrebné.

Vo veľkých projektoch migrácie môže identifikácia úplného vyčerpávajúceho zoznamu zdrojov údajov spravidla trvať pomerne dlho a vyskytuje sa pri pokračovaní práce v ďalších fázach.

Často dochádza k situáciám, kedy je pre ďalšie zabezpečenie integrity informácií potrebné niektoré údaje preniesť z tlačených zdrojov (digitalizovať) alebo dokonca zapísať do tabuliek podľa slov kľúčových zamestnancov zákazníka.

V tejto fáze by ste sa však mali pokúsiť identifikovať čo najviac potrebných údajov.

3.Nahrávanie zdrojových údajov

Proces sťahovania údajov z historických systémov môže trvať pomerne dlho, najmä ak je systémov veľa, sú rôzne a zodpovedajú za ne rôzne divízie Zákazníka. Tento bod sa musí brať do úvahy počas testu a finálnych migrácií.

Ako najpohodlnejšia možnosť sa javí nahrávanie do xls súborov. Mnoho starších IT systémov podporuje túto možnosť.

Môžu existovať aj možnosti nahrávania do formátu csv, dbf, xml a ďalších.

Stojí za zmienku, že z jedného alebo druhého dôvodu (napríklad bezpečnostné problémy) nemôže zákazník v tejto fáze vždy poskytnúť úplné sťahovanie dát! Len dátová štruktúra a niekoľko testovacích pozícií. Môže teda nastať situácia, že pri testovaní a finálnom zaťažení budú v zdrojových tabuľkách zistené nekvalitné dáta, čo povedie k neplánovaným chybám.

Aby sa tento problém minimalizoval, objem testovacích sťahovaní z historických systémov by sa mal dohodnúť vopred.

4. Mapovanie údajov

Mapovanie (mapovanie údajov) - vo všeobecnosti proces porovnávania údajov z historických systémov a prijímajúceho systému. Teda zdrojové údaje a údaje, ktoré sa majú načítať.

Fáza mapovania je najnáročnejšia na prácu a môže zabrať viac ako 50 % všetkej práce na úlohe migrácie.

V tejto fáze je plne zapojená celá pracovná skupina migračného projektu.

V procese mapovania dát je potrebné rozlišovať podetapy tabuľkového mapovania a mapovania polí.

· Mapovanie tabuliek, alebo mapovanie šablón - porovnanie tabuliek zdrojových dát a dátových šablón pre načítanie. Zápas môže byť buď 1:1 alebo N:N. Výsledkom tejto práce je zostavenie a údržba registra mapovania tabuliek. Táto čiastková etapa je potrebná pre ďalšiu čiastkovú etapu terénneho mapovania a pre sledovanie celkového stavu v mapovaní.

Skupina 1C šablón	Názov šablóny 1C	Názov súboru- zdroj	Pravidlá pre generovanie zdrojového súboru	Zodpovedný	Postavenie	Poznámka
NSI	Ukážka_ Nomenklatúra	Nomenk latura.xls	Nastavte výber v systéme N . Uložiť do txt . Otvoriť v xls, stĺpce sú textové . Prvý riadok je hlavička . Počet stĺpcov - 15 . Skontrolujte počet riadkov v txt a xls . Názov hárku je vždy „Hárok1“	Ivanov I.I.	v práci

· Mapovanie polí - mapovanie polí tabuľky v rámci už definovaného mapovania tabuľky. Výsledkom tejto práce je register mapovania terénu.

№pp

Cl. lúka

Požadovaný

Názov poľa šablóny 1C „Template_Nomenclature“

Popis

Názov poľa „Nomenclature.xls“

Algoritmus plnenia

kód

Kód prvku adresára

kód

názov

názov

Áno

Táto skupina

Obsahuje jednu z nasledujúcich hodnôt: . 1 - pre skupiny . 0 - pre prvky

Ak dĺžka kódu=11 znakov a posledné 4 znaky<>"0000", potom je tento prvok "0", inak je skupina "1".

Celé meno

Názov prvku adresára

názov

Ak ThisGroup = 1, potom "", ElseIf ThisGroup = 0, potom Name.

V rámci tejto etapy by sa mali vykonať aj prípadné práce na normalizácii údajov.

5. Príprava transformačných pravidiel

Na rozdiel od predchádzajúcich etáp je táto etapa technická a zahŕňa prácu developera Dodávateľa.

Na základe dohodnutých terénnych mapovacích registrov vypracujú špecialisti Dodávateľa pravidlá pre transformáciu dát.

Pre operatívnu prácu počas prípravných fáz migrácie a ďalej, počas testovacej a finálnej migrácie, je dôležité, aby existovalo vhodné prostredie pre vývoj pravidiel (skriptov) pre transformáciu dát a prostredie pre konverziu zdrojových dát na dáta pre načítanie.

Požiadavky na toto prostredie zahŕňajú:

· Pohodlie a rýchlosť vývoja pravidiel transformácie;

· Rýchlosť konverzie dát. Vstupné a výstupné súbory môžu byť dlhé stovky tisíc riadkov!

· Schopnosť pracovať s niekoľkými vstupnými súbormi súčasne;

· Možnosť uložiť transformačné pravidlá do samostatných súborov.

Pre naše projekty migrácie sme vyvinuli špecializovanú vývojársku pracovnú stanicu, ktorá ako základ využíva štandardné spracovanie 1C Query Console.

Spracovanie Query Console bolo vylepšené, aby umožňovalo priame dotazy na xls súbory.

Tu je príklad kombinácie dvoch zdrojových xls súborov zamestnancov.xls

Kód zamestnanca	Priezvisko	názov	Priezvisko	Dátum narodenia
2423	Ivanov	Ivan	Ivanovič	17.11.1992
1523	Petrov	Bazalka	Aleksandrovič	04.02.1991
4363	Sidorov	Kirill	Nikolajevič	01.05.1995
	Denisov	Denis	Denisovič	01.01.1990

A Operácie.xls so stránkami:

Odpisy

Kód zamestnanca	dátum	Sum
2423	01.02.2014
1523	02.02.2014
4363	03.02.2014
	04.02.2014	100000
2423	05.02.2014
1523	06.02.2014
4363	07.02.2014	2356
	08.02.2014	140000
2423	09.02.2014
1523	10.02.2014
4363	11.02.2014	23523
	12.02.2014	80000

A účtenky:

Kód zamestnanca	dátum	Sum
	01.05.2004
	02.05.2004
	03.05.2004
	04.05.2004
2423Dátum narodenia	Príjmová suma	Odpísaná suma
Ivanov Ivan Ivanovič	2423	17.11.1992	1341234	1010
Petrov Vasilij Alexandrovič	1523	04.02.1991	245245
Denisov Denis Denisovič		01.01.1990	380000	320000
Sidorov Kirill Nikolajevič	4363	01.05.1995	613382	26336
CELKOM:			2579861	347842

Všimnite si, že príklad je umelý, špeciálne vybraný tak, aby demonštroval všetky možné fázy transformácie zdrojov údajov.

Technologická postupnosť transformačných operácií je tu nasledovná:

Pomocou dotazovacieho jazyka Access SQL (ktorý poskytuje významné dodatočné možnosti v porovnaní s dotazovacím jazykom 1C) sa vytvorí úvodný dotaz, ktorý extrahuje údaje zo súboru xls do prostredia 1C. Zároveň sú už v tejto fáze možné rôzne kontroly a normalizácia údajov.

Technológia prístupu k dátam ADO poskytuje vysokú rýchlosť.

Ryža. 3

2. Dotaz v jazyku 1C - hlavný dotaz, ktorý implementuje algoritmus mapovania polí. A tiež: obohatenie sťahovaných dát o dáta z databázy 1C, preskupovanie, spájanie s výsledkami dotazov do iných zdrojových xls súborov atď.

3. V prípade potreby dodatočné spracovanie výsledku požiadavky 1C. Implementované pomocou skriptu v jazyku 1C.

Napríklad tu implementujeme pridanie riadku „TOTAL“ do stĺpcov sumy.

4. Zapíšte konečný súbor údajov do súboru xls.

Vo všeobecnosti sú výstupom konečné súbory na načítanie do cieľovej databázy 1C.

Tento nástroj vám tiež umožňuje uložiť pravidlá konverzie údajov do samostatného súboru xml:

Okrem toho je možné pracovať V dávkový režim, čo je dôležité najmä vtedy, keď existuje veľké množstvo heterogénnych údajov o migrácii.

Počas predchádzajúcich etáp sa prípravná časť práce spravidla končí - identifikujú sa všetky zdroje údajov, stiahnu sa zdrojové údaje zo zdrojov, pripravia sa šablóny na stiahnutie do cieľovej databázy, pripraví sa mapovanie údajov a nakoniec sa vyvinú skripty na transformáciu údajov. .

Treba poznamenať, že pred konečnou migráciou by ste mali určite vykonať niekoľko testov. Počas testovacích migrácií Dodávateľ spolu so Zákazníkmi identifikuje:

Chyby konverzie, chyby načítania údajov

Vykonajte predbežné posúdenie kvality údajov načítaných do cieľového systému

Na základe výsledkov testovacích migrácií vytvoria/aktualizujú konečný plán migrácie

7. Zosúladenie údajov

Kvalita stiahnutých údajov by sa mala skontrolovať po testovacích migráciách a na konci konečnej migrácie. Počas zosúlaďovania je možné skontrolovať tieto ukazovatele:

· Zhoda celkových súm pre zostatky podľa dokladov;

· Kvantitatívne zhody, napríklad počet OS;

· správne naplnenie jednotlivých vybraných subjektov;

Upozorňujeme, že určité kontroly migrujúcich údajov a problémy s normalizáciou údajov musia byť vyriešené počas všetkých procesov migrácie. Vždy si musíte položiť otázku, čo je potrebné urobiť v súčasnej fáze, aby ste sa vyhli chybám v nasledujúcich fázach.

Napríklad:

· Skontrolujte duplikáty podľa kľúčových polí. Môže a mala by sa vykonať na pôvodných údajoch;

· Nátlak typov polí;

· Referenčná integrita;

· Matematické nezrovnalosti. Napríklad kontrola prázdnych číselných polí, do ktorých sa plánuje rozdelenie počas transformácie;

· Vo všeobecnosti platí, že kontrola povinných polí je vyplnená;

· Nahradenie nesprávnych znakov. Napríklad anglické znaky v poliach v azbuke („o“, „a“, „e“ atď.) To platí najmä pre kľúčové polia!

· Kontrola súladu hodnôt polí reťazcov s typmi prijímacieho systému (obmedzenia dĺžky)

Po dokončení finálnej migrácie sa podľa vopred stanovenej migračnej stratégie a plánu migrácie rozhodne o ďalšom fungovaní historických systémov.

Operácia je často ukončená hneď po konečnom vyrovnaní údajov a zaznamenaní úspešnosti migrácie – používatelia nového systému už nevedú evidenciu v dvoch paralelných systémoch, ale úplne prechádzajú na nový systém. Zároveň je prístup k starému systému udržiavaný v režime čítania.

V niektorých prípadoch môže dôjsť k paralelnej prevádzke dvoch systémov počas trvania skúšobnej prevádzky (TE) a dokonca aj po tomto období. S problematikou paralelnej práce používateľov v dvoch systémoch úzko súvisí aj otázka možnosti návratu k starému systému, ak migráciu (alebo vo všeobecnosti fungovanie nového systému!) považujeme za neuspokojivú.

Záver

Na záver by som rád poznamenal, že pokiaľ ide o migráciu veľkých transakčných systémov, ktoré zahŕňajú veľa konfigurácií 1C:Enterprise, prechod na nový systém môže byť veľmi náročný na prácu.

Preto treba pamätať na to, že každý takýto projekt si vyžaduje starostlivú prípravu a musí byť sprevádzaný individuálnym plánom. Bez ohľadu na typ migrovaných systémov, objemy databáz atď. však všeobecná schéma migrácie vyzerá takmer identicky.

• previesť existujúce zdrojové domény do organizačných jednotiek nových domén, čo zjednoduší správu sieťových zdrojov;
• „simulovať“ priebeh migrácie, pričom nedochádza k žiadnemu skutočnému prenosu údajov;
• vrátiť späť prijaté opatrenia súvisiace s migráciou;
• presunúť servisné účty;
• obnoviť dôverný vzťah medzi zdrojovou a cieľovou doménou;
• Konvertujte viacero domén na jednu alebo viac veľkých domén v už vytvorenom prostredí Active Directory;
• reštrukturalizovať existujúce skupiny alebo zlúčiť niekoľko skupín do jednej v cieľovej doméne;
• analyzovať proces prenosu údajov zaznamenávaním udalostí migrácie.

Migrácia používateľov a pracovných staníc do jednej štruktúry Active Directory sa vykonáva pri zachovaní existujúcich prístupových práv.

Možnosti inovácie

Existujú dve hlavné možnosti inovácie infraštruktúry domény [4]:

• Aktualizácia domény. Táto metóda je najbežnejšia a najjednoduchšie implementovateľná pri migrácii domén. Táto metóda umožňuje uložiť aktuálnu štruktúru domény, systémové nastavenia, štruktúru používateľov a skupín. Aktualizácia domény (aktualizácia na mieste) zahŕňa prenos existujúcich radičov domény do novovytvorenej domény.
• Reštrukturalizácia domény. Táto metóda umožňuje zmeniť existujúcu štruktúru domén, zlúčiť domény alebo konvertovať domény na organizačné jednotky.

Okrem vyššie uvedených možností je na nich založená aj zmiešaná možnosť – aktualizácia domén s ich následnou reštrukturalizáciou [13].

Tieto možnosti sú tzv Prechodové cesty pre implementáciu Active Directory. Z nich zvolená prechodová cesta bude hlavným článkom v celkovej stratégii aktualizácie doménovej infraštruktúry. Táto stratégia bude obsahovať popis toho, ktoré objekty adresárovej služby je potrebné presunúť a v akom poradí. Najlepšou praxou pre akýkoľvek presun aplikácie počas implementácie Active Directory je zdokumentovať každý detail v pracovnom dokumente, ktorý sa nazýva plán prechodu.

Kritériá výberu prechodovej cesty

Pri výbere prechodovej cesty sa predpokladá, že rozhodnutie sa týka len jednej domény, čo znamená, že je úplne spravodlivé použiť rôzne prechodové cesty pre rôzne domény v rámci tej istej organizácie.

Pozrime sa na hlavné kritériá, ktoré sa používajú pri výbere najvhodnejšej prechodovej cesty [13], uvedené v tabuľkách 12.1, 12.2, 12.3, 12.4, 12.5, 12.6.

• Kritérium 1. Spokojnosť s existujúcim modelom existujúcej domény. Tabuľka 12.1. Výber prechodovej cesty na základe kritéria 1

  Prechodová cesta	Kritériá oprávnenosti
  Aktualizácia domény	Ak neexistujú žiadne významné zmeny, ktoré by ste chceli vykonať v modeli domény, najjednoduchšiu cestu poskytne aktualizácia domény. Názov domény zostane rovnaký, rovnako ako existencia všetkých používateľských a skupinových účtov
  Reštrukturalizácia domény	Ak súčasný model domény už nespĺňa potreby organizácie alebo už nie je najvhodnejší pre oddelenia organizácie, reštrukturalizácia domény môže byť najlepšou voľbou.

• Kritérium 2. Miera rizika pri prechode na nový model domény. Tabuľka 12.2. Výber prechodovej cesty na základe kritéria 2

  Prechodová cesta	Kritériá oprávnenosti
  Aktualizácia domény	Aktualizácia domény je metóda s nízkym rizikom. Proces inovácie radiča domény je automatický, takže bez zásahu používateľa je malý priestor na chyby. Metodika obnovy po zlyhaní inovácie domény je tiež pomerne jednoduchá: ak inovácia zlyhá, musíte vypnúť primárny radič domény (PDC), priradiť rolu PDC akýkoľvek záložný radič domény (BDC), ktorý má čerstvé údaje, a začnite postup znova
  Reštrukturalizácia domény	Reštrukturalizácia domény je cesta s vyšším rizikom ako obnova domény. Je potrebné dokončiť viac úloh, a preto sa mnohé procesy môžu pokaziť. V dôsledku toho narastá frustrácia medzi používateľmi, ktorí sa nemôžu prihlásiť, nemajú prístup k potrebným zdrojom alebo nemajú prístup k svojim poštovým schránkam.

• Kritérium 3. Čas vykonania prechodu 1 Načasovanie prechodu nie je rozhodujúcim faktorom pri výbere cesty prechodu, ale môže byť určujúcim faktorom pre malé organizácie s obmedzenými zdrojmi. .Tabuľka 12.3. Výber prechodovej cesty na základe kritéria 3

  Prechodová cesta	Kritériá oprávnenosti
  Aktualizácia domény	Obnova domény je lineárny proces: akonáhle bol spustený, musí byť dokončený. Vyžaduje si to menej krokov ako reštrukturalizácia, a preto trvá menej času na dokončenie celého prechodu
  Reštrukturalizácia domény	Reštrukturalizácia domény vždy trvá dlhšie. Napríklad počas reštrukturalizácie sa veľa času strávi budovaním a overovaním infraštruktúry cieľovej domény, presúvaním všetkých účtov zo zdrojovej domény do cieľovej domény. Veľké organizácie nemusia byť schopné presunúť všetky objekty naraz, takže reštrukturalizácia domény sa často vykonáva v niekoľkých fázach

• Kritérium 4: Čas adresárovej služby potrebný na dokončenie procesu migrácie. Tabuľka 12.4. Výber prechodovej cesty na základe kritéria 4

  Prechodová cesta	Kritériá oprávnenosti
  Aktualizácia domény	Objekty účtov nie sú počas procesu migrácie dostupné, pretože sa aktualizujú pri aktualizácii domény
  Reštrukturalizácia domény	Dobrá voľba pre organizácie, v ktorých je systémový pracovný čas kritickou hodnotou. Keďže ide o vytvorenie neobývaného, ​​„čistého“ lesa a ponecháva pôvodné prostredie v podstate nezmenené, funkčnosť adresárovej služby je zachovaná, pretože používatelia naďalej fungujú vo svojom existujúcom prostredí. Počas hodín mimo špičky môžete migrovať veľké alebo malé skupiny používateľov a tieto nové účty nechať nečinné, kým nebudete pripravení opustiť starý systém

• Kritérium 5. Dostupnosť zdrojov na dokončenie prechodu. Tabuľka 12.5. Výber prechodovej cesty na základe kritéria 5

  Prechodová cesta	Kritériá oprávnenosti
  Aktualizácia domény	Keďže aktualizácia domény je automatizovaná operácia, táto prechodová cesta bude vyžadovať menej ľudských zdrojov
  Reštrukturalizácia domény	Reštrukturalizácia domény zahŕňa viac úloh ako obnova domény, a preto si vyžaduje viac zdrojov, čo znamená, že musí byť primerane personálne vybavená, aby zvládla dodatočnú pracovnú záťaž spojenú s reštrukturalizáciou domény. Alternatívou je outsourcing niektorých alebo všetkých projektov: existuje veľa poradenských skupín, ktoré sa špecializujú na takéto projekty, čo šetrí čas a peniaze potrebné na školenie interných zamestnancov.

• Kritérium 6. Rozpočet prechodného projektu. Tabuľka 12.6. Výber prechodovej cesty na základe kritéria 5

  Prechodová cesta	Kritériá oprávnenosti
  Aktualizácia domény	Faktory, ktoré prispievajú k zníženiu požadovaných rozpočtových prostriedkov: schopnosť používať existujúci hardvér servera; nižšie náklady na ľudské zdroje; znížené náklady na testovanie, pretože bude potrebné testovať menej úloh aktualizácie
  Reštrukturalizácia domény	Z mnohých dôvodov si reštrukturalizácia domény bude vyžadovať väčší rozpočet ako obnova domény. Hardvérové ​​požiadavky potrebné na vybudovanie čistého prostredia lesa, do ktorého sa musia migrovať objekty adresárovej služby, by sa mali zvážiť z hľadiska rozpočtu.

Ak spoločnosť úplne nespĺňa podmienky na to, aby si s istotou zvolila obnovu domény alebo reštrukturalizáciu ako cestu obnovy, alebo ak sú pre ňu obe cesty vhodné, môže si zvoliť tretiu cestu – obnovu domény s následnou reštrukturalizáciou.

Táto cesta k Active Directory poskytne okamžité výhody (delegovanie správy, skupinové politiky, publikovanie aplikácií a ďalšie), ako aj dlhodobé výhody reštrukturalizácie domén (menej domén so zvýšeným objemom domén, dizajn domény v súlade s obchodnými a organizačnými cieľmi spoločnosti).