SQL Server'dan Azure SQL Managed Instance'a Göç Nasıl Yapılır? (2026)

Özet (TL;DR): SQL Server 2016'nın desteği 14 Temmuz 2026'da resmi olarak bitti; üç yıllık ücretli güvenlik yaması (ESU) seçeneği de 17 Temmuz 2029'da tükeniyor. Azure SQL Managed Instance, sunucu düzeyinde SQL Server özelliklerinin neredeyse tamamını koruyan, bulutta yönetilen bir hedef sunuyor ve Managed Instance Link özelliğiyle kesinti süresini dakikalara indirebiliyorsunuz. Türkiye'deki kurumlarda en sık gözden kaçan tuzak: hedef örneğin sunucu düzeyi harmanlama (collation) ayarı oluşturma anında sabitleniyor ve sonradan değiştirilemiyor — Logo, Netsis, Mikro gibi Türkçe harmanlama (Turkish_CI_AS) kullanan ERP'lerde bu adım atlanırsa ç/ğ/ş/ı/ö/ü karakterlerinde sıralama ve karşılaştırma hataları ortaya çıkar. Bu rehber, göç yöntemini seçmekten adım adım kesintisiz göçe, collation kontrolünden geri alma (rollback) sınırlarına kadar süreci Microsoft'un güncel resmi belgeleriyle anlatıyor.

Xen Bilişim ekibi — Microsoft Bulut Çözüm Ortağı (CSP Direct Partner, 2016'dan beri), MS-100 / MS-102 / AZ-104 sertifikalı danışmanlardan oluşan veritabanı göç ekibi tarafından hazırlandı.

Neden Şimdi Göç Etmelisiniz? SQL Server 2016 Desteğinin Bitmesi Ne Anlama Geliyor

Microsoft'un resmi SQL Server blogu 14 Temmuz 2026'da yayınladığı duyuruda, SQL Server 2016'nın 10 yıllık destek süresinin sona erdiğini ve bu tarihten sonra düzenli güvenlik güncellemesi sağlanmayacağını açıkladı. Aynı yazıda Microsoft, desteği biten sistemlerin "özellikle yapay zeka destekli tehdit ortamında zaman içinde daha savunmasız hale geldiği" uyarısını yaptı (Microsoft SQL Server Blog, 2026-07-14). Bu, çoğu üretim ve ticaret firmasında hâlâ arka planda çalışan Logo, Netsis, Mikro gibi yerli ERP'lerin veritabanı katmanını doğrudan ilgilendiriyor.

Microsoft üç yol öneriyor: Azure SQL'e geçiş (altyapı yönetimi büyük ölçüde ortadan kalkar), SQL Server 2025'e yerinde yükseltme veya Genişletilmiş Güvenlik Güncellemeleri (ESU) — yani destek süresi bittikten sonra ücretli olarak alınabilen, sadece kritik güvenlik yamalarını kapsayan geçici bir köprü. ESU için üç yıllık pencere 17 Temmuz 2029'da kapanıyor; yani ESU bir çözüm değil, geçiş süresini satın almak.

Bu yazı, üçüncü ve en kalıcı seçeneği — Azure SQL Managed Instance'a (MI) göç — uçtan uca ele alıyor. MI, sunucu düzeyi işlevleri (SQL Agent, çapraz veritabanı sorguları, Service Broker, bağlantılı sunucular) büyük ölçüde koruyan, bu yüzden çoğu ERP/muhasebe uygulamasının kod değişikliği olmadan taşınabildiği yönetilen bir platform. Kurumunuzun lisans yenileme kararını EA/CSP açısından değerlendirmesi gerekiyorsa önce SQL Server lisanslama rehberimize, ESU ile Azure SQL arasında karar veriyorsanız SQL Server 2016 destek sonu karar rehberimize bakabilirsiniz — bu yazı doğrudan "nasıl" sorusuna, adım adım göç sürecine odaklanıyor. Göçü kendi ekibinizle değil uçtan uca yönetilen bir hizmet olarak almak isterseniz ücretsiz bir keşif görüşmesi için bize ulaşabilirsiniz.

Ön Gereksinimler ve Göç Öncesi Değerlendirme

Göçe başlamadan önce netleştirilmesi gereken noktalar:

• Aktif Azure aboneliği ve hedef kaynak grubu üzerinde katkıda bulunan (Contributor) yetkisi.
• Desteklenen SQL Server sürümü — Managed Instance Link, gerekli güncelleme paketi kurulu SQL Server 2016 ve sonrası sürümleri destekliyor; native yedek/geri yükleme yöntemiyle SQL Server 2012 SP1 CU2 öncesine kadar inilebiliyor.
• Ayrılmış bir alt ağ (subnet) — Azure SQL Managed Instance, sanal ağda kendine özel, başka kaynaklarla paylaşılmayan bir alt ağ istiyor; yanlış yapılandırılmış alt ağlar veya eksik hizmet uç noktaları örnek oluşturmayı doğrudan engelliyor.
• Değerlendirme taraması — Azure Migrate, Azure Arc'ın göç hazırlık değerlendirmesi veya Microsoft Assessment and Planning (MAP) Toolkit ile kaynak sunucudaki engelleyici özellikleri önceden tespit edin (Microsoft Learn, Migration Guide).

Bütçe onayından önce süreci test etmek isteyenler için Microsoft, ücretsiz bir SQL Managed Instance teklifi sunuyor: abonelik başına 1 örnek, 4 vCore, ayda 720 vCore saati, 12 ay boyunca, Next-gen General Purpose katmanında 500'e (standart General Purpose'ta 100'e) kadar veritabanı ve 64 GB veri depolama — SLA garantisi olmadan (Microsoft Learn, Free Offer, güncelleme 2026-08-27). Bu, gerçek üretim ortamına dokunmadan collation davranışını ve uygulama uyumluluğunu test etmek için idealdir.

Hangi Göç Yöntemini Seçmelisiniz?

Microsoft'un resmi göç rehberi beş seçenek sunuyor; hangisinin doğru olduğu kesinti toleransınıza ve veritabanı büyüklüğünüze bağlı:

• Azure Arc üzerinden SQL Server göçü — Azure portalından uçtan uca yönetilen, Copilot destekli akış; SQL Server 2012 ve sonrasını destekler, çoğu adımı otomatikleştirir.
• Azure Database Migration Service (Azure DMS) — neredeyse sıfır kesintiyle, portal üzerinden sihirbaz tabanlı göç; büyük ölçekli, çok veritabanlı ortamlar için tercih edilir.
• Managed Instance Link — en düşük kesinti süresini veren yöntem; haftalarca/aylarca açık tutulup istediğiniz an "anlık" kesime (cutover) geçebilirsiniz. Bu yazının odağı bu yöntem.
• Log Replay Service (LRS) — yedekleri Azure Blob Storage'a atıp sürekli/otomatik tamamlama modunda geri oynatma; DMS/MI Link'e alternatif, orta düzey kesinti.
• Native yedekle / URL'den geri yükle — en basit ama en yüksek kesinti süresi gerektiren yöntem; küçük veritabanları veya test ortamları için uygun.

10'dan fazla veritabanınız veya kesinti toleransınız dakikalarla ölçülüyorsa Managed Instance Link'i öneriyoruz; birden fazla veritabanını aynı sunucudan taşıyorsanız Microsoft, aynı anda en fazla 8 veritabanını paralel taşımanızı, geri kalanları sırayla planlı yük devretmelerle taşımanızı tavsiye ediyor. Fiziksel sunucudan tüm Azure altyapısına geçişi birlikte planlıyorsanız fiziksel sunucudan Azure'a geçiş rehberimize de göz atabilirsiniz.

Adım Adım: Managed Instance Link ile Sıfıra Yakın Kesintiyle Göç

Managed Instance Link, SQL Server'ın Always On kullanılabilirlik grubu teknolojisini kullanarak birincil sunucudan Azure SQL Managed Instance'a neredeyse gerçek zamanlı veri çoğaltması yapar. Kesinti yalnızca son "kesim" (cutover) anında yaşanır (Microsoft Learn, Migrate with the Link).

1. Hedef SQL Managed Instance'ı oluşturun. Azure portalı, PowerShell (New-AzSqlInstance) veya Azure CLI (az sql mi create) ile — kaynak sunucunun harmanlama (collation) ayarını burada zaten belirlemiş olmanız gerekiyor (bkz. bir sonraki bölüm).
2. Ortamı bağlantı için hazırlayın. Ağ bağlantısı, gerekli portlar ve sertifika değişimi Microsoft'un "link preparation" rehberinde adım adım anlatılıyor.
3. Bağlantıyı yapılandırın. SQL Server Management Studio (SSMS) sihirbazıyla veya T-SQL/PowerShell script'leriyle kaynak ve hedef arasında link kurulur.
4. Replikasyon gecikmesini izleyin. Planlı kesime geçmeden önce ikincil kopyanın birincile yetiştiğinden emin olun; aşağıdaki sorguyu hem SQL Server'da hem Managed Instance'da çalıştırın:

   -- Hem SQL Server'da hem SQL Managed Instance'ta çalıştırın
   USE master
   DECLARE @link_name varchar(max) = '<DAGname>'
   SELECT
      ag.name [Link name],
      ars1.role_desc [Link role],
      ars2.connected_state_desc [Link connected state],
      ars2.synchronization_health_desc [Link sync health],
      drs.secondary_lag_seconds [Link replication latency (seconds)]
   FROM
      sys.availability_groups ag
      JOIN sys.dm_hadr_availability_replica_states ars1 ON ag.group_id = ars1.group_id
      JOIN sys.dm_hadr_availability_replica_states ars2 ON ag.group_id = ars2.group_id
      JOIN sys.dm_hadr_database_replica_states drs ON ars2.replica_id = drs.replica_id
   WHERE ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
   GO

5. Planlı kesinti penceresinde iş yükünü durdurun. En kolay yöntem, uygulama bağlantılarını sunucudan kesmek.
6. Veriyi doğrulayın ve gecikmenin sıfıra indiğini teyit edin.
7. Planlı yük devretme (planned failover) başlatın ve "Remove link after successful failover" seçeneğini işaretleyin — göç senaryosunda önerilen budur. İlk tam yedekleme tamamlanmadan link'i kaldırırsanız, örnek yeniden başlatıldığında veritabanının geçici olarak erişilemez hale geldiği nadir bir bilinen sorun var; bu yüzden ilk tam yedekleme bitene kadar bekleyin.
8. Uygulamaları yeni uç noktaya yönlendirin ve izlemeye başlayın.

Kesim davranışı kaynak sürüme göre değişir: SQL Server 2016-2019'dan göçte kesim sırasında link otomatik olarak düşer ve geri dönüş mümkün değildir. SQL Server 2022 ve sonrasından göçte, uyumlu bir güncelleme politikasıyla link korunabilir ve gerekirse geri göç yapılabilir — bu farkı geri alma bölümünde detaylandırıyoruz.

Bu adımları kendi ekibinizle yürütmek yerine uçtan uca yönetilen bir hizmet olarak almak isterseniz Azure danışmanlık hizmetlerimizi inceleyebilir veya WhatsApp'tan hızlıca yazabilirsiniz.

Kritik Tuzak: Collation ve Türkçe Karakterler (Logo, Netsis, Mikro Entegrasyonlarında)

Harmanlama (collation), bir veritabanı motorunun metinleri hangi kurallarla sıraladığı ve karşılaştırdığı ayar setidir — bir sözlüğün hangi dile göre alfabetik dizildiğine benzer. Yanlış harmanlamayla taşınan bir veritabanında "İ" ile "I" karışabilir, "ç/ğ/ş/ö/ü" karakterleri yanlış sıralanabilir veya iki metin aslında aynıyken sistem onları "farklı" sayabilir.

Azure SQL Managed Instance'ın varsayılan sunucu düzeyi harmanlaması SQL_Latin1_General_CP1_CI_AS'dir (kod sayfası 1252). Türkçe karakter setini tam destekleyen Turkish_CI_AS ise 1254 kod sayfasını kullanır — çoğu Türkiye'de kurulmuş SQL Server'ın varsayılanıdır ve Logo Tiger, Netsis Fusion, Mikro Fly gibi yerli ERP'lerin çoğu bu harmanlamayı bekleyerek kurulmuştur.

Kritik nokta: Managed Instance'ın sunucu düzeyi harmanlaması yalnızca örnek oluşturulurken belirlenebiliyor ve sonrasında değiştirilemiyor (Microsoft Learn, Set or Change the Server Collation). Yani göçe "varsayılan ayarlarla" başlayıp sonra düzeltmek mümkün değil — örneği silip yeniden oluşturmanız gerekir.

Yapılması gereken:

• Göçten önce kaynak sunucuda SELECT SERVERPROPERTY('Collation'); çalıştırıp gerçek harmanlamayı tespit edin.
• Hedef Managed Instance'ı oluştururken Azure portalında "Gelişmiş yapılandırma" (Advanced configuration) veya PowerShell/CLI'da ilgili -Collation / --collation parametresiyle aynı harmanlamayı açıkça belirtin — asla varsayılana güvenmeyin.
• Logo/Netsis/Mikro gibi ERP'lerde bağlantı dizesinde veya raporlama katmanında sabit kodlanmış harmanlama varsayımları olup olmadığını yazılım sağlayıcınızla teyit edin.
• Ücretsiz Managed Instance teklifiyle önce bir test örneği kurup uygulamanızı bu örneğe karşı deneyin — collation hatası üretim ortamına geçmeden önce burada yakalanır.

Türkiye'den Azure'a Göçte Ek Dikkat Noktaları

Türkiye'de yerel bir Azure bölgesi bulunmuyor; en yakın bölgeler Batı Avrupa (Hollanda) ve Polonya Merkez. Bu iki şeyi doğrudan etkiler: (1) uygulama-veritabanı gecikme süresi, özellikle yoğun senkron sorgu yapan ERP modüllerinde test edilmeli; (2) verinin fiziksel olarak yurt dışında saklanması nedeniyle KVKK'nın yurt dışına veri aktarımı hükümleri (6698 sayılı Kanun madde 9) devreye girer. Kurul'un onayladığı Standart Sözleşme mekanizmasıyla bu aktarım hukuki zemine oturtulabiliyor; kesin uygulama şirketinizin veri envanterine göre değiştiği için bu değerlendirmeyi hukuk/uyum ekibinizle birlikte yapmanızı öneririz; kapsamlı bir uyum değerlendirmesi için güvenlik ve uyum hizmetlerimizden destek alabilirsiniz.

Yaygın Göç Engelleyicileri ve Çözümleri

Microsoft'un resmi göç rehberi, göçe başlamadan önce kontrol edilmesi gereken sık karşılaşılan engelleri şöyle listeliyor:

• Desteklenmeyen özellikler — bazı SQL Server özellikleri Managed Instance'da yok; başlamadan önce göç değerlendirmesi (migration assessment) çalıştırılmalı.
• Sanal ağ yapılandırması — yanlış yapılandırılmış alt ağ, eksik hizmet uç noktası veya hatalı ağ güvenlik grubu (NSG) kuralı örnek oluşturmayı veya bağlantıyı engeller.
• Oturum açma ve kullanıcı geçişi — SQL Server oturum açma bilgileri ve veritabanı kullanıcıları otomatik taşınmaz; kaynaktaki oturum açma bilgilerini script'leyip hedefte yeniden oluşturmanız, SID uyuşmazlığından doğan "sahipsiz kullanıcı" (orphaned user) sorununa dikkat etmeniz gerekir.
• SQL Server Agent işleri — zamanlanmış işler, uyarılar ve operatörler veritabanıyla birlikte taşınmaz; ayrıca script'lenip hedefte yeniden kurulmalıdır.
• TDE korumalı veritabanları — saydam veri şifrelemesi (TDE) kullanılıyorsa, geri yükleme öncesi sertifikanın hedef örneğe taşınması zorunludur; aksi halde geri yükleme başarısız olur.
• Veritabanı boyutu ve aktarım hızı sınırları — büyük veritabanları seçtiğiniz hizmet katmanının kaynak sınırlarını aşabilir; hedef yapılandırmayı önceden doğrulayın.

Ayrıca, hızlandırılmış veritabanı kurtarma (accelerated database recovery) özelliği açıksa ve kalıcı sürüm deposu (PVS) birincil dosya grubunda değilse, geri yükleme hataları yaşanabiliyor — göçten önce PVS'yi PRIMARY dosya grubuna almanız öneriliyor. Kaynakta Service Broker kapalıysa hedefte de kullanılamıyor; göçten önce etkinleştirin.

Göç Sonrası Doğrulama ve Test Adımları

Kesim tamamlandıktan sonra, göçün gerçekten başarılı olduğunu kanıtlamadan üretime geçmeyin:

1. Doğrulama sorguları geliştirin — kaynak ve hedefte aynı sonucu vermesi gereken T-SQL sorguları hazırlayın (satır sayısı, toplamlar, kritik iş kuralları).
2. İzole bir test ortamı kurun — kaynağın ve hedefin birer kopyasını, üretimi etkilemeyecek şekilde ayrı tutun.
3. Doğrulama testlerini çalıştırın ve sonuçları karşılaştırın.
4. Performans testlerini çalıştırın — göç öncesi kaynak sunucuda oluşturduğunuz performans temeliyle (baseline) karşılaştırın; sorgu planlarında beklenmedik yavaşlama olup olmadığını kontrol edin.

Göç tamamlandıktan sonra Managed Instance'ın yerleşik özelliklerinden yararlanın: otomatik yüksek kullanılabilirlik, tehdit algılama ve merkezi izleme/ayarlama artık platformun bir parçası, ayrı bakım işi gerektirmiyor. Kapasite/performans planlıyorsanız, Next-gen General Purpose katmanı — Kasım 2025'te genel kullanıma açıldı — aynı temel maliyetle 5 kat veritabanı kapasitesi ve 2 kat aktarım hızı sunuyor (Microsoft Learn, What's new, güncelleme 2026-08-17); yeni bir göçte doğrudan bu katmanı seçmek genelde daha avantajlı.

Geri Alma (Rollback) Notu: Ne Zaman Mümkün, Ne Zaman Değil

Managed Instance Link ile göç sonrası eski sunucuya dönüş, kaynağın SQL Server sürümüne sıkı sıkıya bağlı: SQL Server 2022 veya SQL Server 2025 güncelleme politikasıyla yapılandırılmış bir Managed Instance'daki veritabanı, uyumlu sürüme geri yüklenebilir. Ama SQL Server 2016, 2017 veya 2019'dan göç ediyorsanız, veritabanı Managed Instance'a taşınırken dahili olarak daha yeni bir veritabanı sürümüne yükseltiliyor ve bu, eski sürümle uyumlu değil — yani geri göç mümkün değil.

Pratik sonucu: SQL Server 2016/2019'dan göç ediyorsanız kesim öncesi son bir tam yedek alın ve kaynak sunucuyu belirlediğiniz bir gözlem penceresi boyunca (örneğin 2-4 hafta) kapatıp saklayın, hemen kaldırmayın. Sorun çıkarsa bu yedekten yeni bir SQL Server örneğine geri dönebilirsiniz — ama Managed Instance'daki veritabanını doğrudan eski sunucuya "geri göç" olarak taşıyamazsınız.

Saha Vakası: Orta Ölçekli Bir Üretim Firmasında SQL Server Göçü

Firma X — 140 kişilik bir metal işleme ve otomotiv yan sanayi üreticisi — Logo Tiger ERP'sinin çalıştığı, sahadaki bir sunucu odasında barındırılan SQL Server 2016 örneğini Azure SQL Managed Instance'a taşıdı. Tetikleyici, SQL Server 2016'nın destek sonu tarihinin yaklaşması ve sunucu donanımının 7 yaşına gelmiş olmasıydı.

Süre: 5 hafta (1 hafta değerlendirme + 2 hafta test ortamı doğrulaması + kesim gecesi).

Karar noktaları: (1) Kaynak sunucunun Turkish_CI_AS harmanlamasıyla kurulu olduğu tespit edildi; hedef Managed Instance bu harmanlamayla açıkça oluşturuldu, varsayılana bırakılmadı. (2) Üretim planlama modülünün gece toplu işleri (batch job) nedeniyle kesim penceresi hafta sonu gece yarısına planlandı. (3) SQL Server Agent üzerinde çalışan 11 zamanlanmış işin tamamı script'lenip hedefte yeniden oluşturuldu, üçü Managed Instance'ın yerleşik yedekleme özelliğiyle artık gereksiz hale geldiği için kaldırıldı.

Sonuç: Planlı kesinti süresi 22 dakika ile sınırlı kaldı; Logo Tiger tarafında herhangi bir Türkçe karakter/sıralama hatası yaşanmadı çünkü collation testi, ücretsiz Managed Instance örneğinde göçten iki hafta önce yapılmıştı. Xen ekibinin rolü: göç değerlendirmesi, collation doğrulaması, Managed Instance Link kurulumu ve kesim gecesi canlı izleme. Uyarı: Bu vakada asıl riskin teknik göç değil, üretim planlama ekibiyle kesim penceresinin doğru koordine edilmesi olduğu görüldü — göç takvimini her zaman iş birimleriyle birlikte belirleyin.

Sonuç: SQL Server Göçü Artık Ertelenecek Bir Proje Değil

SQL Server 2016'nın desteğinin bitmiş olması, göçü "bir gün yaparız" listesinden çıkarıp somut bir takvime bağlıyor. Azure SQL Managed Instance, Managed Instance Link sayesinde kesinti süresini dakikalara indirebilen, sunucu düzeyi SQL Server işlevselliğini büyük ölçüde koruyan olgun bir hedef sunuyor. Ama Türkiye'deki kurumlar için tek başına teknik bir "taşıma" projesi değil — collation, KVKK ve yerli ERP entegrasyonu gibi yerel katmanları da kapsayan bir plan gerektiriyor.

Doğru sırayla ilerlerseniz (değerlendirme → doğru harmanlamayla hedef oluşturma → link ile test → planlı kesim → doğrulama), göç riskli bir "büyük patlama" değil, öngörülebilir bir proje haline gelir.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun SQL Server'dan Azure SQL Managed Instance'a göç yolculuğunda değerlendirmeden kesim gecesine kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın veya WhatsApp'tan yazın.

Sadece SQL Server değil, veritabanının bağlı olduğu tüm sunucu/uygulama katmanını da bulut kararına bağlamak istiyorsanız ürün ve hizmetler sayfamızdan Xen Bilişim'in sunduğu yönetilen BT paketlerinin tamamına göz atabilirsiniz.

Sıkça Sorulan Sorular (SSS)

Azure SQL Managed Instance'a göç ne kadar sürer?

Veritabanı büyüklüğüne ve yönteme göre değişir; Managed Instance Link ile hazırlık ve test dahil tipik bir orta ölçekli ERP veritabanı göçü 3-6 hafta sürer, ama gerçek kesinti süresi (uygulamanın erişilemez olduğu süre) genelde 20-40 dakikayla sınırlı kalır.

SQL Server 2016 desteği bitti, hemen mi göç etmeliyim yoksa ESU mu almalıyım?

ESU (Genişletilmiş Güvenlik Güncellemeleri) yalnızca kritik güvenlik yamalarını kapsayan, üç yıl (17 Temmuz 2029'a kadar) sürebilen ücretli bir köprüdür — kalıcı çözüm değildir. Göç planınızı bu pencere içinde tamamlamanızı öneririz; ESU'yu yalnızca göç projesi için zaman kazanmak amacıyla kullanın.

Logo, Netsis, Mikro gibi Türkçe collation kullanan ERP'lerde göç riski var mı?

Evet — bu yazının en kritik uyarısı bu. Managed Instance'ın sunucu düzeyi harmanlaması yalnızca oluşturma anında belirlenir ve sonradan değiştirilemez. Kaynaktaki gerçek harmanlamayı (genelde Turkish_CI_AS) önceden tespit edip hedefte açıkça belirtmezseniz, ç/ğ/ş/ı/ö/ü karakterlerinde sıralama ve karşılaştırma hataları alırsınız.

Managed Instance Link ile göç sırasında ne kadar kesinti yaşanır?

Link haftalarca açık kalabilir ve veri neredeyse gerçek zamanlı çoğaltılır; gerçek kesinti yalnızca planlı yük devretme (cutover) anında yaşanır — bu, Microsoft'un sunduğu yöntemler arasında en düşük kesinti süresini veren seçenektir.

Göç sonrası eski SQL Server'a geri dönebilir miyim?

Yalnızca kaynağınız SQL Server 2022 veya 2025 ise ve hedef Managed Instance uyumlu güncelleme politikasıyla yapılandırıldıysa. SQL Server 2016/2017/2019'dan göçte veritabanı dahili olarak yükseltildiği için geri göç mümkün değildir; bu yüzden kesim öncesi kaynağı belirli bir süre kapalı tutup saklamanızı öneririz.

Azure SQL Managed Instance fiyatı nasıl hesaplanır, ücretsiz deneyebilir miyim?

Fiyatlandırma vCore, depolama ve hizmet katmanına (General Purpose / Business Critical) göre değişir ve bölgeye göre farklılaşabildiği için güncel rakamı Azure'un resmi fiyatlandırma sayfasından hesaplamanızı öneririz. Test amaçlı, abonelik başına 1 örnek, 4 vCore, ayda 720 vCore saati ve 12 ay boyunca geçerli ücretsiz bir teklif mevcut — üretim kararı vermeden önce collation ve uygulama uyumluluğunu bu ücretsiz örnekte doğrulayabilirsiniz.

Verilerim Türkiye dışına mı taşınıyor, KVKK açısından sorun olur mu?

Türkiye'de yerel bir Azure bölgesi olmadığı için veri fiziksel olarak yurt dışında (genelde Batı Avrupa veya Polonya Merkez bölgesinde) barınır. Bu, KVKK'nın yurt dışına veri aktarımı hükümlerini devreye sokar; Kurul'un onayladığı Standart Sözleşme mekanizmasıyla hukuki zemine oturtulabilir. Kesin değerlendirmeyi işlenen veri türüne göre hukuk/uyum ekibinizle birlikte yapmanızı öneririz.