PMS Geçişinde Data Migration ve Temizlik Süreci Nasıl Yönetilir?

Data migration, bir PMS Implementation projesinde “bir defalık” bir adım gibi görünür; ama etkisi yıllar sürer. Misafir kartları hatalıysa kişiselleştirme bozulur, şirket/acenteler kirliyse ticari raporlar karışır, fiyat anlaşmaları yanlış taşınırsa gelir tarafı risk alır. Üstelik veri kalitesi düşerse, ekip yeni PMS’i “suçlar” ve benimseme (adoption) zayıflar.

Bu riski daha geniş PMS & OTA yönetimi çerçevesi içinde görmek gerekir; çünkü migration kalitesi yalnızca veri taşıma değil, dağıtım, raporlama ve operasyon güveni konusudur.

Örnek (yönlü ifade): Veri temizliği yapılmadan taşınan CRM/misafir kartları; raporlama ve kişiselleştirme projelerinde ciddi gürültü yaratır; doğru migration bunun tam tersi etki yapar.

☑ Mini Check: “Yeni PMS’te 1 ay sonra raporlara güvenecek miyiz?”

En büyük hata, “madem geçiyoruz, her şeyi taşıyalım” yaklaşımıdır. Doğru yaklaşım: veriyi operasyonel zorunluluk, ticari devamlılık ve analitik değer katmanlarına ayırmak ve her katmanda “taşınır/temizlenir/taşınmaz” kararı vermektir. Ayrıca “tarihçe” konusu kritik: her otel, geçmişin ne kadarını yeni PMS’te canlı tutacağına karar vermelidir.

Veri sınıflandırma: Taşınır / Temizlenir / Taşınmaz

• •Taşınır (çekirdek): oda planı, fiyat planları, şirket/acenteler, kullanıcı yetkileri, aktif rezervasyon/konaklama kuralları
• •Temizlenerek taşınır: misafir kartları, CRM alanları, tarihçe seçimi (kural setiyle)
• •Taşınmaz (genelde): gereksiz kişisel notlar, artık kullanılmayan eski kodlar, “tanımsız” serbest metin alanları (KVKK riskli olabilir)

Buraya: “Data alan listesi tablosu” (alan adı, kaynak, hedef, taşınır/temizlenir/taşınmaz, sorumlu)

Antalya/Belek senaryosu: yılların biriktiği misafir kartı verisi

Antalya / Belek gibi yıllardır aynı PMS’i kullanan otellerde en sık durum şudur: misafir kartı sayısı çoktur ama kayıtların önemli kısmı duplicate, eksik veya tutarsızdır. Bu yüzden “hepsini taşıma” yerine; tekilleştirme (dedup), alan standardı ve tarihçe sınırı ile taşımak daha güvenlidir.

Duplicate kayıt, eksik alan, bozuk tarih formatı ve standardizasyon kararlarını daha derin okumak için PMS veri kalitesi ve temizlik rehberi migration sürecinin hygiene tarafını tamamlar.

☑ Mini Check: “Taşıdığım veri, yeni PMS’te karar kalitesini artıracak mı; yoksa gürültü mü üretecek?”

Migration’ın başarısı, adımların netliğine bağlıdır. “Excel’den içeri atarız” yaklaşımı yerine, data mapping + kontrollü import + doğrulama üçlüsüyle ilerlemek gerekir.

Kaynak verinin Excel veya manuel dosyalardan geldiği senaryolarda süreç biraz daha disiplin ister. Bu tip geçişler için Excel’den PMS’e geçiş planlama içeriği, legacy sistemden PMS’e geçiş tarafında pratik bir köprü kurar.

Adım adım migration akışı (uygulamalı)

1. Legacy System envanteri: hangi kaynaklar var? (eski PMS, Excel, farklı departman dosyaları)
2. Alan eşleme (Data Mapping): kaynak alan → hedef PMS alanı → dönüşüm kuralı
3. Temizlik kuralları: duplicate, boş alan, format standardı (telefon, ülke, e-posta vb.)
4. Test ortamında deneme import: küçük örneklem + kontrollü genişleme
5. Doğrulama raporları: sayım kontrolü, örnek kayıt kontrolü, kritik rapor tutarlılığı
6. Üretim import + log: hatalar ve düzeltmeler kayıt altına alınır
7. Go-live sonrası kalite kontrol: ilk raporlar + saha geri bildirimiyle düzeltme döngüsü

Buraya: “Eski→Yeni alan eşleme (mapping) diyagramı”

☑ Mini Check: “Mapping dokümanım yoksa, veri taşıma şans işidir.”

Migration testleri sadece “yükledi mi?” değildir; “yükledikten sonra raporlar ve iş akışı doğru mu?” testidir. Bu yüzden doğrulama, hem IT hem operasyon checklist’i içermelidir.

Canlıya çıkış öncesi son güvenlik ağı için PMS Go-Live ve İlk 7 Gün Kontrol Listesi ile mapping ve doğrulama sonuçlarını aynı akışta kontrol etmek gerekir.

Migration test checklist’i (örnek)

• •Kaynak kayıt sayısı vs hedef kayıt sayısı (toleranslı kontrol)
• •Zorunlu alanlar dolu mu? (oda tipi, fiyat planı, şirket/acenteler)
• •Format doğruluğu (telefon, e-posta, ülke kodu)
• •Duplicate kontrol sonucu (kaç kayıt birleşti/atıldı)
• •Örnek misafir kartı: “tek kayıt” davranışı doğru mu?
• •Örnek rezervasyon/fiyat: kural doğru çalışıyor mu?
• •Rapor doğrulama: muhasebe ile temel tutarlılık

Buraya: “Migration test checklist’i” görseli + “Hata & düzeltme log” örneği

Hata & düzeltme log mantığı (minimum)

• •Hata ID / Tarih
• •Kaynak veri / hedef alan
• •Hata tipi (format/boş/duplicate/mapping)
• •Düzeltme aksiyonu
• •Sorumlu kişi
• •Yeniden test sonucu

☑ Mini Check: “Hata log’um yoksa, aynı hatayı tekrar üretirim.”

Go-live’dan sonra veri kalitesi korunmazsa, birkaç ay içinde eski sorunlar geri gelir. Data Quality için minimum bir “ritim” gerekir: standart giriş kuralları, periyodik temizlik ve raporlama kontrolü.

Temiz taşınan veri, yalnızca operasyon akışını değil veri analiz ve raporlama kalitesini de doğrudan etkiler. Migration sonrası raporlar bozuluyorsa sorun çoğu zaman dashboard’da değil veri temelindedir.

Basit ama etkili kalite ritmi

• •Haftalık: duplicate kontrolü (misafir kartı, şirket/acenteler)
• •Aylık: alan doluluk ve format raporu
• •90 gün: mapping ve iş kuralı gözden geçirme (ne bozuluyor?)
• •Eğitim: en çok hata yapılan 3 alan için mini eğitim

☑ Mini Check: “Kalite kuralı yoksa, PMS’e değil veri disiplinine ihtiyacınız vardır.”

1. Veriyi sınıflandırın: taşınır/temizlenir/taşınmaz kararını verin
2. Data Mapping yapın: kaynak→hedef alan + dönüşüm kuralı dokümante edin
3. Temizlik kuralları belirleyin: duplicate, format, boş alan, tarihçe sınırı
4. Test import uygulayın: örneklem → genişletme yaklaşımıyla ilerleyin
5. Doğrulayın: sayım + örnek kayıt + kritik rapor tutarlılığı
6. Go-live sonrası kalite ritmi kurun: hata log’u + rapor kontrol döngüsü

• •Önce hangi veriyi taşıyacağınıza karar verin (çekirdek + temizlenerek taşınacaklar).
• •Alanları eşleyin (mapping): kaynak alan → yeni PMS alanı → dönüşüm kuralı.
• •Duplicate ve çöp kayıtları temizleyin; test ortamında küçük import’la başlayın.
• •Hata log’u tutun, düzeltip yeniden import edin.
• •Go-live sonrası ilk raporlarla veriyi doğrulayın ve kalite ritmi kurun.

Data migration sırasında gereksiz kişisel veriyi “alışkanlıkla” taşımak, hem risk hem maliyettir. KVKK’ya uygun saklama süresi yaklaşımıyla; sadece operasyonel/ticari devamlılık için gerekli veriyi taşıyın, gereksiz alanları dışarıda bırakın. Gerekli durumlarda maskeleme (ör. tam veri yerine kısmi görünüm) ve erişim yetkisi (role-based access) ile riski azaltın.

Bu aşamada KVKK & veri güvenliği çerçevesi ile veri taşıma, erişim ve loglama kurallarını netleştirin. Sürecin hukuki ve operasyonel uyum tarafını güçlendirmek için de KVKK uyum hizmeti yaklaşımını migration planına dahil edin.

Bu içerik, PMS geçişinde migration’ı yalnızca veri taşıma değil; veri seçimi, temizlik, mapping, test ve go-live sonrası kalite ritmi olarak ele alır. Doğru kurgulanan bir süreç, hem operasyonu sakinleştirir hem de raporlara güveni artırır.

Bir sonraki adım için PMS kurulum hizmeti sayfasına geçebilir, migration ve geçiş sürecine dair detay soruları kapatmak için PMS kurulum hakkında sık sorulan sorular bölümünü inceleyebilirsiniz.