Büyük projelerde veri geçişi teknolojisi. Veri geçişini düzenleme metodolojisi Veri geçişi nedir

Veri geçişi, depolanan dijital bilgilerin bilgisayarlar, sistemler veya formatlar arasında taşınmasıdır. Veri geçişi, sunucu değişimi veya bakımı, veri merkezi değişiklikleri, veri birleştirme projeleri ve sistem yükseltmeleri dahil olmak üzere çeşitli nedenlerle gerçekleşir. Bir şirketin kurumsal bilgisinin ve iş zekasının büyük bir kısmı kendi verilerinde bulunduğundan, riski en aza indirmek için herhangi bir veri taşıma projesinin dikkatli bir şekilde yürütülmesi gerekir.

“Veri geçişi” BOŞALTILIYOR

Veri geçişi, yanlış yapılması durumunda önemli bir iş sürekliliği riski oluşturur. Veri kaybı elbette en kötü senaryodur ancak şirketlerin aynı zamanda kesinti, uyumluluk sorunları ve genel sistem performansı sorunlarıyla da uğraşması gerekir. Verilerin büyük miktarda olması, farklı veri formatları ve şirketler arasındaki veri farklılıkları nedeniyle veri geçişi zordur.

Veri geçişi risklerini en aza indirmek için şirketler, gerektiğinde yedeklemeleri duraklatan, sıralamayı taşıyan ve paralel veri ortamlarını düzenleyen ayrıntılı veri taşıma politikaları oluşturur. Bir şirket yeni bir ortam hazırlarken geçiş öncesi ortamı çalıştıramazsa, mevcut uygulamalardaki iş operasyonları veri geçişine izin vermek için duraklatıldığından önemli bir kesinti yaşanacaktır. Bu tür durdurma, taşıma, başlatma geçişi, yeni platformlara geçiş yaparken veya sıkı fiziksel depolama kısıtlamaları olduğunda ve mevcut depolama teknolojisi takas veya yama gerektirdiğinde gerekli olabilir.

Verileri sıfır kesinti süresiyle taşıyın

Sıfır kesinti süreli geçiş modeli, iki eksiksiz ortamı oluşturmak ve çalıştırmak için yeterli depolama alanına sahip olmanıza dayanır. Çalışanlar eski ortamda kalırken şirket verilerinin tam bir kopyası yeni ortama alınır ve doğrulanır. Hatalar yeni sistem üzerinden giderilerek tüm uygulamaların hala çalıştığı ve her şeyin olması gerektiği yerde olduğu garanti ediliyor. Test tamamlandığında yeni bir kopya görünür ve tüm çalışanlar yeni ortama taşınır. Çalışanların eski veri sistemindeki dosyaları alabilmesi ancak bu sunuculara yeni veri yazamaması için eski veri ortamı bazen aylarca açık bırakılır. Tüm veri geçişleri, veri kaybını kontrol etmek için geçiş sonrası veri incelemesi gerçekleştirir.

Veri geçişini iyileştirebilecek şeylerden biri, geçiş öncesinde veri uygulamalarını temizlemek ve standartlaştırmaktır. Bir şirketin verilerinin organizasyonu genellikle çalışanlarının farklı dosyalama alışkanlıklarının bir yansımasıdır. Aynı role sahip iki kişi tamamen farklı yöntemler kullanabilir. Örneğin, bir durumda sözleşmelerin tedarikçi tarafından sürdürülmesi, diğerinde ise mali yıl ve ay boyunca sürdürülmesi. Veri uygulamalarını birleştirmek, verileri fiilen taşımaktan çok daha önemli bir görev olabilir, ancak net politikalarla desteklenen temiz, tutarlı bir şekilde organize edilmiş veriler, bir şirketin verilerinin gelecek birçok geçiş için geleceğe hazır olmasına yardımcı olur.

Sergey Berdaçuk, 1.0 2006.12.01

Görünüşe göre mevcut bir bilgi sisteminin (IS) varlığı, eskisine dayalı yeni bir IS'nin gelişimini basitleştirmeli ve hızlandırmalıdır, ancak pratikte her şey genellikle tam tersi olur. İlk olarak, yeni bir IS oluşturmaya ihtiyaç duyulduğundan, bu çoğunlukla önceden oluşturulmuş IS'nin önemli kusurlarla oluşturulduğu ve çeşitli hatalarla dolu olduğu anlamına gelir.

Genellikle yıllar boyunca çeşitli geliştiriciler tarafından yazılan bir IP'den. Aynı zamanda, proje dokümantasyonu çoğunlukla acınası bir durumdadır ve bazen tamamen yoktur. "Gerçek" programcılar belge yazmazlar, program kodunu belgelemezler. Neden, çünkü her şey basit ve şeffaf. Ancak altı ay sonra kendi kodunuza baktığınızda orada ne yapıldığını anlamak oldukça zor. Özellikle bu süre zarfında başka birçok proje tamamlanmışsa.

Üstelik her yeni geliştirici genellikle kodu veya sistem mimarisini dikkatlice inceleme zahmetine girmez. Son teslim tarihleri ​​her zaman tükendiğinden, acil soruna geçici bir çözüm bulmak için sadece "aletler" yazarlar. Sonuç, birçok farklı modülden ve bir şekilde mucizevi bir şekilde birleştirilmiş, bazen birbiriyle uyumsuz teknolojilerden oluşan bir "yulaf lapası"dır. Bu durum, veri depolama için dbase-III, FoxPro veya Clipper gibi eski veritabanı yönetim sistemlerinin (DBMS) kullanılmasıyla daha da kötüleşiyor. İşlem kavramının olmayışı, beceriksiz tasarım ve referans bütünlüğü, veri bütünlüğünün çok sayıda ihlaline yol açmaktadır. Eski sistem bir DBMS kullanıyorsa kendinizi şanslı sayabilirsiniz; bazen verileri depolamak için metin dosyaları kullanan yaratımlarla karşılaşırsınız (bu sistemlerden birini taşırken, yazarın böyle bir veritabanına erişmek için özel bir sürücü yazması gerekiyordu).

Belki de tek olumlu yön, yeni geliştirilen IS için gereksinimlerin oluşturulmasında birikmiş deneyimdir. Öte yandan eski sistemle ilgili deneyim, yeni bir ürünün piyasaya sürülmesinde önemli bir engel haline gelebilir. Çoğu zaman bu, görsel arayüzün tasarımındaki ve belirli işlemleri gerçekleştirmek için kullanılan işlev tuşlarındaki farklılıklar nedeniyle oluşur. Böylece, bazı işlev tuşları işletim sistemi tarafından belirli eylemleri gerçekleştirmek üzere rezerve edilebilir. Tipik bir örnek, eski DOS sistemlerinde düzenlenebilir bir formun bir sonraki öğesine geçmek için "Enter" tuşunun kullanılmasıdır. Grafiksel arayüzlerde genellikle bu amaçla “Tab” tuşu kullanılır. Sonuç olarak, ürünün yeni bir versiyonunu piyasaya sürerken kullanıcılardan güçlü tepkiler alıyoruz. Elbette eski sistemin UI (Kullanıcı Arayüzü) arayüzünün davranışını taklit edebilirsiniz, ancak bu en iyi şekilde isteğe bağlı olarak yapılır. Onlar. IS yapılandırma modülünde sistem davranışını yapılandırma yeteneğini tanıtın ve varsayılan olarak mevcut işletim sistemine karşılık gelen ayarları kullanın. Aksi takdirde yeni geliştirilen ürünün, programın güncel standartlara uygun davranmasını bekleyen yeni kullanıcılar tarafından öğrenilmesi zorlaşacaktır.

Eski sistemin depolanan verileriyle çalışmaya gelince durum daha da kötü. En ciddi sonuçlar, yönetimin eski sistemin bazı modüllerini kullanma kararı olacaktır. Örneğin, depo muhasebesinin yeni bir versiyonunu geliştirme göreviyle karşı karşıya kaldığımızda, geri kalan görevler (muhasebe vb.) IS'nin eski versiyonu tarafından ele alınacaktır. Bu çalışma modunda verilerin “gerçek” zamanlı olarak taşınması sorunu ortaya çıkar. Tüm modüllerin bir bütün olarak çalışmasını sürdürmenin genel giderleri, tüm modüllerin yeni bir versiyonunun geliştirilmesinin maliyetlerini aşabilir. Ayrıca, eski sistemin eksikliklerinden kaynaklanan olası kayıplar ve veri alışverişi ve dönüşümündeki hatalar dikkate alındığında maliyetler büyüklük sırasına göre farklılık gösterebilir. Bu nedenle eski fikri mülkiyetin durumu ve yapılabilirliği dikkatle değerlendirilmelidir. Ve en ilginç olanı, pratikte bu sorun ortaya çıkana kadar genellikle değinilmemesidir: "Yeni bir sistem oluşturalım, sonra diğer yazılımlarla bağlantı kurma ve verileri taşıma işlemlerini halledeceğiz."

Ama sonra sorunun olgunlaştığı, yeni bir sistemin yazıldığı ve verileri dönüştürüp yeni sisteme aktarmanın zamanı geldiği an gelir. Çok sayıda farklı bilgi sisteminden veri taşıma deneyimini analiz ederek, aşağıdakileri içeren tipik bir veri taşıma prosedürünü tanımlayabiliriz:

• Eski ve yeni veri tabanı yapısına ait veri formatlarının analizi, veri taşıma ve dönüştürme planının hazırlanması;
• Tablolar arasındaki ilişkilerin tanımlanması (nesnelerin hiyerarşisi);
• Bağımlılık hiyerarşisine uygun olarak veri indirme sırasının belirlenmesi. Bazen, ancak her zaman değil (örneğin, veritabanının yeni bir sürümü zaten üretimde olduğunda), ilişkileri göz ardı etmek ve geçişten önce tüm yabancı anahtarları devre dışı bırakmak ve tüm veri manipülasyonu tamamlandıktan sonra bunları yeniden oluşturmak mümkündür;
• Veritabanının yeni sürümündeki nesneleri değiştirmek için bir komut dosyası çalıştırma;
• “Anında” gerekli dönüşümlerle doğrudan veri aktarımı;
• Devre dışı bırakılan dizinleri, ek dönüşümleri vb. geri yüklemek için bir komut dosyası çalıştırın. Veri taşıma prosedürünü tamamladıktan sonra.

En basit seçenek genellikle bir ara katman yazılımı oluşturmaktır. Kaynak ve hedef veritabanları ile iletişim kurmalı ve gerekli dönüşümleri yapmalıdır.

Pirinç. 1. Veri geçişi için ara katman yazılımı seçeneği

Bu çözümün önemli bir dezavantajı, veri aktarımı sırasında ağ yükü olabilir. Veri hacmi önemliyse ağ trafiğinin performans üzerinde önemli bir etkisi olabilir.

Daha uygun maliyetli bir çözüm, eski verileri yeni DBMS'nin geçici tablolarına önceden yüklemek olabilir. Modern DBMS'ler (örneğin Oracle) genellikle çeşitli formatlardaki harici verileri çok hızlı bir şekilde indirmenize olanak tanıyan özel yardımcı programlar içerir. Geçiş modülünün kendisi, DBMS'de yerleşik prosedür dilleri (örneğin, PL/SQL veya Java) kullanılarak yazılmıştır. Yerleşik programlama dillerinin “yerel” ortamda çalışması, hedef DBMS için optimize edilmiş olması ve ağ üzerinden veri alışverişi için herhangi bir ek yük olmaması nedeniyle geçiş prosedürünün hızını önemli ölçüde artırabilirsiniz.

Pirinç. 2. DBMS kullanarak veri taşıma seçeneği

Bu tür programların yazılmasındaki pratik deneyimimden yola çıkarak, çoğu DBMS ve programlama dili tarafından desteklenen toplu SQL yöntemlerinin (örneğin, Java'daki addBatch() ve executiveBatch() yöntemleri) kullanımına dikkat çekmek istiyorum. Bir veri dizisinde 100 - 200 kayıtlık gruplar halinde bir INSERT veya UPDATE güncelleme ifadesinin yürütülmesi, bu ifadenin her kayıt için bir döngüde tek tek yürütülmesine kıyasla önemli bir performans artışı sağlar.

Veri göçü

Veri geçişi, veritabanlarının, yazılımların, finansal veya diğer iş verilerinin farklı BT sistemleri arasında taşınmasını içeren çok adımlı bir süreçtir. İyi düşünülmüş bir geçiş planı, veritabanlarının, programların ve uygulamaların yanı sıra diğer verileri, beklenmedik iş süreci aksama süresi riskleri olmadan sağlayıcının bulutuna sorunsuz bir şekilde aktarmanıza olanak tanır. DEAC, kendi veya üçüncü taraf BT ekipmanınızdan DEAC veri merkezlerinin altyapısına adım adım güvenilir veri aktarımı sağlar.

Adım adım geçiş planı
DEAC uzmanları tüm veri geçiş sürecini izleyip belgeleyerek proje şeffaflığını ve verimliliğini korur

Buluta veya sunucuya geçiş
DEAC, coğrafi konum ve kullanılan veri depolama sistemleri ne olursa olsun, veri kaybı riski olmadan tam veri entegrasyonunu sağlayacaktır.

Aktif iş süreçleri üzerinde minimum etki
Ayrıntılı bir geçiş planı, teknik uyumsuzluk sorunlarına veya beklenmeyen kesintilere karşı koruma sağlarken tam uygulama performansını da korur

Veri merkezleri, iş büyümesinin güvenilir veri geçişi ve iş yükü taşınmasını gerektirdiği kritik bir iş unsuru haline geldi. İster veri merkezleri arasında geçiş, ister konsolidasyon, felaket kurtarma planı veya bulut altyapısının yeniden inşası olsun, DEAC projeyi başarılı bir şekilde yürütmek için deneyimli ekip, araçlar ve bilgi sağlayacaktır. DEAC, dünyanın önde gelen tedarikçileri ve satıcılarıyla işbirliği yaparak müşteriye geçişin tüm aşamalarında tek bir iletişim noktası sağlar.
Bu yaklaşım, hem sanal hem de fiziksel veri geçişi için karlı, risksiz bir geçiş stratejisi sağlar.

Deneyimli bir servis sağlayıcı seçin ve kaliteyi yakalayın
ve sorunsuz bir veri taşıma süreci.

DEAC'ın uzun yıllara dayanan deneyimi, sertifikalı uzmanlar ve esnek altyapı, güvenilir veri geçişini garanti eder veri merkezleri artan güvenlik seviyesi. Süreçlerin sürekliliğini sağlamak için DEAC uzmanlarının geçiş sırasında özel dikkati, veri ve uygulamaların başarılı bir şekilde taşınması, bütünlüğü, gizliliği ve güvenliğine yöneliktir. Verileriniz yerleştirilebilir özel, genel veya hibrit bulut, ve üzerinde özel veya sanal sunucu, yüksek hızlı bağlantılarla. Uzmanlarımız BT sistemi gereksinimlerinizi karşılayan özel veya anahtar teslim bir çözüm seçmenize yardımcı olabilir.

Bulut geçişi

Veritabanı geçişi

Uygulama geçişi

DEAC, müşterinin kendi altyapısından buluta veya bir bulut ortamından diğerine eksiksiz bir geçiş süreci sağlar ( buluttan buluta geçiş). Verileri, bilgi depolamayı, uygulamaları ve diğer BT iş öğelerini buluta taşımak, beklenmedik kesintiler olmadan güvenliği ve kullanılabilirliği korumanıza olanak tanır. DEAC, verilerin veya sistemlerin tam entegrasyonu için özel bulut araçlarını kullanır.

Veritabanı geçişi, yazılım platformunun değiştirilmesini içerir; bu nedenle, en yüksek uyumluluğu sağlamak ve uygulama düzeyinde hata riskini azaltmak için hazırlık aşamasında her iki platformun da tam denetimi gerçekleştirilir. Sertifikalı uzmanlarımız, sistemlerin maksimum güvenliğini ve işlevselliğini koruyarak tüm veritabanı geçiş sürecini buluta belgeliyor.

Uygulamaların, yeni ortamdan farklı olabilecek kendi veri mimarisi ve özel platform konfigürasyonu vardır; bu nedenle, kendi uygulamalarınızı taşırken adım adım bir geçiş planı oluşturmalısınız. Kapsamlı bir uygulama geçişi yaklaşımı, kritik verileri korumanıza, doğru yolda kalmanıza ve proje bütçesi dahilinde kalmanıza yardımcı olur. DEAC, her müşteri için gerekli veri hacmine, uygulama türüne, kaynak teknolojilerine ve müşterinin seçtiği BT altyapısına karşılık gelen bireysel bir geçiş planı geliştirir.

DİĞER HİZMETLER HAKKINDA DAHA FAZLA BİLGİ EDİNİN:

PLM endüstrisi on yıldan fazla bir süredir gelişiyor ve başlangıçta seçilen çözümleri deneyen işletmelerin, mevcut PLM'yi bir başkasıyla değiştirmeye oldukça makul bir şekilde karar verdikleri veya mevcut PLM'nin yapılandırmasını önemli ölçüde değiştirmeye karar verdikleri an geldi. Ve burada PLM verilerinin eski sistemden yenisine taşınması sorunu ortaya çıkıyor. Bildiğimiz gibi, geometrik verilerin çevrilmesi bile zor ve belirsiz bir şekilde çözülmüş bir iştir; PLM verilerinin taşınması ise daha karmaşık ve hala az bilinen bir süreçtir.

Nasıl oluyor

Yeni bir PLM sisteminin seçimi yapıldı, yönetim ekibi bu seçimin zorlu çabasının sonucunu kutlamanın rahatlığını yaşadı. Aslında, verilerin mevcut sistemlerden yeni hedef PLM platformuna geçişini planlamak ve yürütmek gibi gerçek iş ancak şimdi başlıyor. Bir şirketin mevcut verileri önemli miktarda fikri mülkiyet (IP) ve dolayısıyla şirketin rekabet avantajı ve sermayesini içerir. Yeni bir sistemin uygulanmasının başarısı büyük ölçüde mevcut verilerin akıllı, yüksek kaliteli ve zamanında etkili bir şekilde taşınmasına bağlıdır.

Bu senaryo dünya çapında ve her sektörde şu veya bu şekilde düzenli olarak tekrarlanıyor. Teknolojideki hızlı ilerlemeyle birlikte artan rekabet baskıları, birçok şirketin PLM çözümlerini sürekli olarak değerlendirdiği ve iyileştirmeler yaptığı anlamına geliyor. Karar, mevcut çözümün veya daha sıklıkla bakımının veya birden fazla sistemin kullanılmasının şirket yönetimi için tatmin edici olmadığının kabul edilmesiyle verilebilir. Ek olarak, diğer bir ortak tema ise şirketin satın almalarının etkisi ve çeşitli PLM çözümlerinin konsolidasyonunun garanti olduğunun farkına varılmasıdır. Diğer bir senaryo ise mevcut platformun büyük ölçüde yeniden yapılandırılması ihtiyacıdır. Değişikliğin nedenleri ne olursa olsun, değişikliğin etkili bir şekilde uygulanması, mevcut verilerin yeni platforma başarılı bir şekilde taşınmasına bağlı olacaktır.

Veri taşıma sorunları

Veri geçişi birçok sorunu ön plana çıkarıyor. Örneğin bunun, şirketin ürün verilerini yönetmeyi nasıl seçtiğine ilişkin uzun yıllardan beri yapılan ilk inceleme olduğu ortaya çıkabilir. Zaman içinde gelişen mevcut veri modelindeki bariz eksikliklerin üstesinden gelmek için bir şirketin modelin bazı kısımlarını değiştirmesi veya genişletmesi gerekebilir. Her durumda, bu değişiklikler eskiden yeniye geçiş süreci üzerinde ilave baskı oluşturacaktır ve verilerin basitçe taşınması mümkün olmayabilir. Geçişin en önemli yönlerinden biri, öncelikle incelemeye tabi olan tüm verileri tanımlamanız gerekmesidir. Birçoğu yalnızca dijital verilerin aktarımından bahsettiğimize inanıyor, ancak deneyimli uzmanlar şirketin kritik fikri mülkiyetinin bir kısmının hâlâ basılı biçimde, hatta önde gelen çalışanların kafasında olabileceğini kesinlikle anlayacaklardır.

Taşınacak veriler belirlendikten sonra, bunların doğruluğunu doğrulamak için süreçler geliştirilmeli ve yürütülmelidir. Çoğunlukla, verilerin önceki sürümlerinde son değişiklikler yapılmadığından veriler güncelliğini kaybetmiş olabilir. Ek olarak, sürekli veya periyodik tutarlılık kontrolleri ve veri temizliği gerektiren yinelenen veriler sıklıkla kullanılır (veya birden fazla sistemde tutulur). Taşınacak verilerin tam kapsamının belirlenmesi, şirketin en deneyimli çalışanlarının bilgi sahibi olmasını gerektirir.

Veri geçişinin belki de en büyük zorluklarından biri geçişin zamanlamasıdır. Şirket çalışmalarını durduramayacağı ve yeni PLM uygulamasının tamamlanmasını bekleyemeyeceği için eski veriler sürekli güncellenecek ve değiştirilecektir. Buna ek olarak, gerçekte, geçişi gerçekleştiren ekibin gerçek geçiş için çok sınırlı teknik zaman dilimleri vardır; bunlar genellikle hafta sonları veya tatil günleridir. Mevcut takvim süresini karşılama ihtiyacı, veriler kolaylıkla yüzbinlerce (hatta milyonlarca) kayıt içerebildiğinden, özel araçlar kullanılarak geçiş algoritmalarının uygulanmasını gerektirir.

Örnek çözüm

PLM verilerini düzenli olarak gerçekleştiren ve taşıyanların deneyimlerine dönelim. PLM veri geçişi alanında tanınmış uzmanlardan biri, bu tür hizmetleri ve bunların uygulanması için etkili araçları sağlama konusunda on bir yıllık deneyime sahip olan Alman PRION Group şirketidir. PRION'un portföyü, verilerin taşınması gereken en yaygın PDM'ler ve eski sistemler için arayüzler içerdiğinden, şirketin her özel durumda geçiş yazılımını yeniden geliştirmesine gerek yoktur. Bu, şirkete özel bir geçiş planını hızlı bir şekilde geliştirmenize ve ürün ve üretim geliştirme üzerindeki etkiyi en aza indirmek için geçişi hızlı bir şekilde tamamlamanıza olanak tanır. Aşağıdaki şekil PRION metodolojisini kullanan tipik bir veri taşıma sürecinin diyagramını göstermektedir.

En önemli şey, bu planın işlevselliğinin çok sayıda PRION istemcisi için tamamlanan PLM veri taşıma projeleriyle defalarca doğrulanmış olmasıdır. Üstelik, verileri bir PLM sisteminden diğerine doğrudan aktarmaya yönelik tekrarlanan girişimler, bu tür ilkel bir yaklaşımın %100 etkisiz olduğunu kanıtladı. Verinin birden fazla kaynaktan toplanması, verinin dönüştürülmesi, temizlenmesi, sertifikalandırılması ve fiziksel olarak da dağıtılabilen yeni sistem(ler)e yüklenmesi ihtiyacı bu durumu belirleyen faktörler arasında yer alıyor. Bu nedenle yeni bir PLM platformuna geçiş yaparken kesinlikle dikkate alınması gereken bir şey yoktur.

Bu riskleri azaltmak için PRION, ara veritabanı kullanan geçiş araçları geliştirmiştir. Veriler bir aşamalandırma veritabanına aktarılır ve yeni hedef PLM platformuna yüklenmeden önce bu veritabanında dönüştürülür. Bu yaklaşım, operasyonel verilerde anında bir değişikliğe yol açmaz ve veri taşıma sürecinin kuralları ve detayları geliştirilirken işler her zamanki gibi devam edebilir. Geçişin başarısı açısından kritik olan, yalnızca verilerin taşınması sırasında yapılan değişiklikleri değil, aynı zamanda yeni PLM platformuna yüklendikten sonra verilerde yapılan değişiklikleri de takip edecek bir değişiklik yönetimi sistemi oluşturmaktır. Bu değişiklik yönetimi sistemi, geçiş sürecinden yeni sistemin sahada başlatılmasına kadar müşterinin özel gereksinimlerini desteklemelidir.

PRION'un geçmiş müşterileri için geliştirilmiş geniş kütüphanesindeki geçiş komut dosyalarının çoğunu kullanabilmesi, geçiş risklerini azaltır ve gelecekteki müşteriler için maliyetleri önemli ölçüde azaltır. Bu yaklaşım, özellikle hedef sistemin dağıtılmış bir çözüm olduğu durumlarda, birçok zor geçiş senaryosunda yardımcı olur.

PRION araçları ve hizmetleri hakkında daha detaylı bilgi için web sitesini ziyaret etmenizi tavsiye ederim.

• mevcut kaynak etki alanlarını, ağ kaynaklarının yönetimini kolaylaştıracak yeni etki alanlarının organizasyonel birimlerine aktarmak;
• Gerçek bir veri aktarımı gerçekleşmezken geçişin ilerleyişini "simüle edin";
• geçişle ilgili gerçekleştirilen eylemleri geri alın;
• hizmet hesaplarını taşıyın;
• eski haline getirmek güvene dayalı ilişki kaynak ve hedef alanlar arasında;
• Önceden oluşturulmuş bir Active Directory ortamında birden fazla etki alanını bir veya daha fazla büyük etki alanına dönüştürün;
• mevcut grupları yeniden yapılandırmak veya birkaç grubu hedef alanda tek bir grup halinde birleştirmek;
• geçiş olaylarını günlüğe kaydederek veri aktarım sürecini analiz edin.

Kullanıcıların ve iş istasyonlarının tek bir Active Directory yapısına geçişi, mevcut erişim hakları korunarak gerçekleştirilir.

Yükseltme seçenekleri

Etki alanı altyapısını yükseltmek için iki ana seçenek vardır [4]:

• Etki alanı güncellemesi. Bu yöntem, alan adlarını taşırken uygulanması en yaygın ve en kolay yöntemdir. Bu yöntem mevcut etki alanı yapısını, sistem ayarlarını, kullanıcı ve grup yapısını kaydetmenizi sağlar. Etki alanı güncellemesi (yerinde güncelleme), mevcut etki alanı denetleyicilerinin yeni oluşturulan etki alanına aktarılmasını içerir.
• Etki alanının yeniden yapılandırılması. Bu yöntem, alan adlarının mevcut yapısını değiştirmenize, alan adlarını birleştirmenize veya alan adlarını kuruluş birimlerine dönüştürmenize olanak tanır.

Yukarıdaki seçeneklere ek olarak, bunlara dayanan karma bir seçenek de vardır - alanların daha sonra yeniden yapılandırılmasıyla güncellenmesi [13].

Bu seçenekler denir Active Directory Uygulaması için Geçiş Yolları. Bunlardan seçilen geçiş yolu, alan adı altyapısının güncellenmesine yönelik genel stratejinin ana bağlantısı olacaktır. Bu strateji, hangi dizin hizmeti nesnelerinin hangi sırayla taşınması gerektiğine ilişkin bir açıklama içerecektir. Active Directory uygulaması sırasında herhangi bir uygulama taşıma işlemine ilişkin en iyi uygulama, her ayrıntıyı geçiş planı adı verilen bir çalışma belgesinde belgelemektir.

Geçiş yolunu seçme kriterleri

Bir geçiş yolu seçerken, kararın yalnızca bir alanla ilgili olduğu varsayılır; bu, aynı kuruluş içindeki farklı alanlar için farklı geçiş yollarının kullanılmasının tamamen adil olduğu anlamına gelir.

Tablo 12.1, 12.2, 12.3, 12.4, 12.5, 12.6'da verilen en uygun geçiş yolunu [13] seçerken kullanılan ana kriterleri ele alalım.

• Kriter 1. Mevcut alanın mevcut modelinden memnuniyet. Tablo 12.1. Kriter 1'e göre bir geçiş yolunun seçilmesi

  Geçiş yolu	Uygunluk kriterleri
  Alan adı güncellemesi	Alan adı modelinde yapmak istediğiniz önemli bir değişiklik yoksa alan adını güncellemek en kolay yolu sağlayacaktır. Alan adı ve tüm kullanıcı ve grup hesaplarının varlığı aynı kalacaktır
  Etki alanı yeniden yapılandırması	Mevcut etki alanı modeli artık kurumsal ihtiyaçları karşılamıyorsa veya kuruluşun departmanları için artık en uygun değilse, etki alanının yeniden yapılandırılması en iyi seçim olabilir.

• Kriter 2. Yeni bir etki alanı modeline geçişteki risk derecesi. Tablo 12.2. Kriter 2'ye göre bir geçiş yolunun seçilmesi

  Geçiş yolu	Uygunluk kriterleri
  Alan adı güncellemesi	Alan adını yükseltmek düşük riskli bir yöntemdir. Etki alanı denetleyicisi yükseltme işlemi otomatiktir, dolayısıyla kullanıcı etkileşimi olmadan hataya çok az yer vardır. Etki alanı yükseltme hatasından kurtarma yöntemi de nispeten basittir: Yükseltme başarısız olursa, birincil etki alanı denetleyicisini (PDC) kapatmanız, yeni verilere sahip herhangi bir yedek etki alanı denetleyicisini (BDC) PDC rolüne atamanız ve prosedüre tekrar başlayın
  Etki alanı yeniden yapılandırması	Alan adının yeniden yapılandırılması, alan adı yenilemeye göre daha yüksek riskli bir yoldur. Tamamlanması gereken daha fazla görev var ve bu nedenle birçok süreç ters gidebilir. Sonuç olarak, oturum açamayan, gerekli kaynaklara erişemeyen veya posta kutularına erişemeyen kullanıcılar arasında artan bir hayal kırıklığı yaşanıyor.

• Kriter 3. Geçiş 1 yürütme süresi Geçişin zamanlaması, geçiş yolunun seçilmesinde belirleyici bir faktör değildir ancak sınırlı kaynaklara sahip küçük kuruluşlar için belirleyici bir faktör olabilir. .Tablo 12.3. Kriter 3'e göre bir geçiş yolunun seçilmesi

  Geçiş yolu	Uygunluk kriterleri
  Alan adı güncellemesi	Alan adı yenileme doğrusal bir süreçtir: Bir kez başlatıldığında tamamlanması gerekir. Yeniden yapılanmaya göre daha az adım gerektirir ve bu nedenle tüm geçişin tamamlanması daha az zaman alır
  Etki alanı yeniden yapılandırması	Etki alanının yeniden yapılandırılması her zaman daha uzun sürer. Örneğin, bir yeniden yapılandırma sırasında, hedef etki alanının altyapısını oluşturmak ve doğrulamak, tüm hesapları kaynak etki alanından hedef etki alanına taşımak için çok fazla zaman harcanır. Büyük kuruluşlar tüm nesneleri aynı anda taşıyamayabilir, bu nedenle etki alanının yeniden yapılandırılması genellikle birkaç aşamada yapılır.

• Kriter 4: Geçiş işlemini tamamlamak için gereken dizin hizmeti süresi. Tablo 12.4. Kriter 4'e göre bir geçiş yolunun seçilmesi

  Geçiş yolu	Uygunluk kriterleri
  Alan adı güncellemesi	Hesap nesneleri, etki alanı yükseltildiğinde otomatik olarak güncellendiklerinden geçiş işlemi sırasında kullanılamaz.
  Etki alanı yeniden yapılandırması	Sistem çalışma süresinin kritik bir değer olduğu kuruluşlar için iyi bir seçim. Doldurulmamış, "temiz" bir orman oluşturulmasını içerdiğinden ve orijinal ortamı temelde değişmeden bıraktığından, kullanıcılar mevcut ortamlarında çalışmaya devam ettikçe dizin hizmetinin işlevselliği korunur. Yoğun olmayan saatlerde büyük veya küçük kullanıcı gruplarını taşıyabilir ve eski sistemden ayrılmaya hazır olana kadar bu yeni hesapları hareketsiz bırakabilirsiniz.

• Kriter 5: Geçişi tamamlamak için kaynakların mevcudiyeti. Tablo 12.5. Kriter 5'e göre bir geçiş yolunun seçilmesi

  Geçiş yolu	Uygunluk kriterleri
  Alan adı güncellemesi	Alan adı güncellemesi otomatik bir işlem olduğundan bu geçiş yolu daha az insan kaynağı gerektirecektir
  Etki alanı yeniden yapılandırması	Etki alanı yeniden yapılandırması, etki alanı yenilemesinden daha fazla görev gerektirir ve bu nedenle daha fazla kaynak gerektirir; bu, etki alanı yeniden yapılandırmasıyla ilişkili ek iş yükünü kaldırabilecek yeterli sayıda personele sahip olunması gerektiği anlamına gelir. Bir alternatif de projenin bir kısmını veya tamamını dış kaynaklardan temin etmektir: Bu tür projelerde uzmanlaşmış birçok danışmanlık grubu mevcut olup, iç personeli eğitmek için gereken zamandan ve paradan tasarruf sağlar.

• Kriter 6. Geçiş projesi bütçesi. Tablo 12.6. Kriter 5'e göre bir geçiş yolunun seçilmesi

  Geçiş yolu	Uygunluk kriterleri
  Alan adı güncellemesi	Gerekli bütçe fonlarındaki azalmaya katkıda bulunan faktörler: mevcut sunucu donanımını kullanma yeteneği; daha düşük insan kaynağı maliyetleri; Daha az yükseltme görevinin test edilmesi gerekeceğinden test maliyetlerinde azalma
  Etki alanı yeniden yapılandırması	Birçok nedenden dolayı alan adının yeniden yapılandırılması, alan adının yenilenmesinden daha büyük bir bütçe gerektirecektir. Dizin hizmeti nesnelerinin taşınması gereken çıplak bir orman ortamı oluşturmak için gereken donanım gereksinimleri, bütçe perspektifinden değerlendirilmelidir.

Bir şirket, yenileme yolu olarak alan adı yenilemeyi veya yeniden yapılandırmayı güvenle seçme koşullarını tam olarak karşılamıyorsa veya her iki yol da ona uygunsa, o zaman üçüncü bir yol seçebilir: alan adı yenileme ve ardından yeniden yapılandırma.

Active Directory'ye giden bu yol anında faydalar sağlayacaktır (yönetim yetkisinin verilmesi, grup politikaları, uygulama yayınlama ve daha fazlası) ve ayrıca alan adı yeniden yapılandırmasının uzun vadeli avantajları (artan alan hacmiyle daha az alan adı, şirketin iş ve organizasyonel hedeflerine uygun alan adı tasarımı).