# Migration

Hesapları SSH üzerinden cPanel ya da DirectAdmin'den içe aktarır; uçtan uca ölçülen iki kaynak bunlardır. Sihirbaz kaynak sunucuda Plesk, HestiaCP, CyberPanel, CloudPanel ve CWP'yi de algılar ve başka bir WHost sunucusundan o sunucunun API'si üzerinden (SSH'siz) içe aktarabilir; bu kaynaklar henüz ölçülmedi ve taşıma betada deneyseldir (bkz. *Bilinen Kısıtlar*). Başka bir WHost sunucusundan içe aktarma hesabın `public_html` (yerine konur) ve `mail` (birleştirilir) klasörlerini dizin tanıtıcıları üzerinden hesabın kullanıcısı olarak yazar — hesap burada zaten varsa da: hesabın `public_html` adına koyduğu bağ düz klasörle değiştirilir, `mail` adındaki bağ üzerinden yazılmaz, o hesabın içe aktarımı başarısız olur. Panel her işi durumunu yoklayarak izler; API ilerlemeyi ayrıca SSE akışı olarak da verir (`GET /migration/status/{job_id}/stream`).

| Adım | Aksiyon |
|---|---|
| 1 | Kaynak sunucu kimlik bilgileri (SSH host, port, root/sudo kullanıcı, parola veya anahtar) |
| 2 | Tarama — agent hesap listesini çeker ve sistem yöneticisinin hangilerini migration edeceğini seçmesine izin verir (domain pattern ile filtre) |
| 3 | Başlat — hesap başına, bu sırayla: hesabı burada oluştur, dosyaları kopyala (`.htaccess` kuralları denetlenir, LSCache tespit edilir), veritabanları ve posta kutuları (her biri atlanabilir), ardından cron işleri ve FTP hesapları. SSL sertifikaları taşınmaz — burada yeniden alın (bkz. SSS) |
| 4 | Her hesap bitene ya da başarısız olana kadar işi izle |
| 5 | Geçiş — siteleri ve postayı burada kontrol et, sonra alan adlarının DNS'ini bu sunucuya yönelt; DNS kayıtları sizin için dışa aktarılmaz ya da karşılaştırılmaz |

Başarısız hesaplar, taramanın SSH kimlik bilgileri hâlâ bellekteyken yeniden denenebilir; biten hesaplar yeniden çalışmaz. Agent yeniden başlatması süren işi sürdürmez: iş başarısız işaretlenir ("Server restarted during migration") ve kimlik bilgileri gider; yeniden denemeden önce kaynak sunucuyu yeniden tarayın (yoksa `400 MIGRATION_CREDENTIALS_EXPIRED`). SSH kimlik bilgileri bellekte AES-şifreli tutulur ve iş tamamlandıktan sonra sıfırlanır.

**Aktarımın koruduğu sınırlar.** Kaynak sunucunun SSH host anahtarı ilk kullanımda sabitlenir (`/var/lib/whost/migration_known_hosts`); sonraki bir uyuşmazlık bağlantıyı parmak iziyle birlikte keser. Dosyalar ve posta kutuları bu sunucuda **taşınan hesabın kendi kullanıcısı olarak** açılır; kaynak arşivin içeriği o hesabın zaten yazabildiği yerlerin dışına ulaşamaz. Yalnızca hesabın kendi önekiyle (`<kullanıcı>_*`) adlandırılmış veritabanları yerelde oluşturulur; kaynağın bildirdiği başka bir ad uyarıyla atlanır. Dökümleri yedek geri yüklemesindeki gibi içe aktarılır — yalnız hesabın kendi veritabanlarına yazabilen içe aktarma kullanıcısıyla (bkz. *Yedekler — kapsam ve ayarlar*): başka bir veritabanını adlandıran döküm o ifadede reddedilir, ajan günlüğü veritabanını adlandırır. Özel/loopback/link-local adres aralıkları kaynak host olarak reddedilir.

**Yüklenen yedek dosyasından geri yükleme yoktur.** Yukarıdaki adımlarla SSH üzerinden taşıyın. Panelde Yükleme sekmesi yoktur; `POST /migration/upload` ve `POST /migration/upload/restore` dosyayı saklamadan `409 MIGRATION_UPLOAD_RESTORE_UNAVAILABLE` döner.

**API uçları:** `POST /migration/scan`, `GET /migration/scan/{job_id}`, `POST /migration/start`, `GET /migration/status/{job_id}`, `GET /migration/status/{job_id}/stream` (SSE), `POST /migration/cancel/{job_id}`, `POST /migration/retry/{job_id}`, `GET /migration/history`, `GET /migration/history/{job_id}`.

---