> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# Mevcut bir SaaS'i supastack'e taşımak

Çalışan bir SaaS'i — auth, kiracılık, faturalandırma, işler — yeniden yazım ya da kesintili bir hafta sonu olmadan supastack temeline taşımak için aşamalı bir yol haritası.

_Yayınlandı 2026-10-29._
_2026-10-29 tarihinde güncellendi._

> **Mevcut bir SaaS'i supastack'e nasıl taşırım?**
> Kod tabanınıza bağlıdır, ancak sıra değişmez: asla tek bir yeniden yazımla değil, aşamalar hâlinde taşıyın. Depoyu ürün kodu (rotalar, şema, alan mantığı — size ait kalır) ve altyapı (auth, kiracılık, faturalandırma, işler, e-posta — kit onu değiştirir) olarak envantere ayırın. Modülleri bağımlılık sırasıyla benimseyin: yapı, auth, çalışma alanları, faturalandırma, ardından arka plan işleri. Verileri yeniden çalıştırılabilir bir betikle taşıyın, Stripe müşteri ID'lerini koruyun ve kabul testleri geçtikten sonra geçiş yapın. Çoğu web uygulaması haftalarca değil, birkaç akşamlık çalışmayla taşınır.

## Koda dokunmadan önce envanter çıkarın

Kötü giden her taşıma aynı şekilde başlar: biri kit deposunu açar ve dosyaları silmeye başlar. Kit bir temeldir, tema değil — altyapınızı değiştirir ve ürününüz hakkında bir fikri yoktur. Herhangi bir şeyi taşımadan önce deponuzu dürüstçe iki yığına ayırın.

Ürün kodu, bir müşterinin size geri anlatabileceği her şeydir: rotalarınız, şemanız, alan mantığınız, metinleriniz, fiyatlandırma sayfanız. Altyapı, onların asla görmediği her şeydir: oturumlar, kiracılık denetimleri, ödeme webhook'ları, kuyruktaki işler, işlemsel e-posta. İlk yığın olduğu gibi taşınır. İkincisi değiştirilir — asıl amaç da budur.

- Her rota grubunu listeleyin ve ürün ya da tesisat olarak etiketleyin — acımasız olun; yalnızca bir webhook URL'sini değiştiren bir ayarlar sayfası tesisattır.
- Ortam değişkenlerinizi listeleyin ve hangilerinin altyapıyı (auth sırları, sağlayıcı anahtarları) hangilerinin ürün davranışını yapılandırdığını işaretleyin.
- Tablolarınızı listeleyin ve hangilerinin kite ait olacağını (kullanıcılar, oturumlar, çalışma alanları, faturalandırma durumu) hangilerinin size ait olduğunu işaretleyin.
- Size para kazandıran tek kullanıcı yolculuğunu yazın — bu akış, aşağıdaki her aşamanın kabul testidir.


## Her birleşim noktasını bir kit modülüne eşleyin

Kitin altyapısı, aralarında sözleşmeler olan bir modül kümesidir — sizin işiniz, eski tesisatınızın her parçasını artık ona sahip olan modüle yönlendirmektir. Eşlemenin çoğu bire birdir; bire bir olmadığı yerler, gerçek kararlar verdiğiniz yerlerdir.

İki eşleme seçimi mekanik taşıma yerine gerçek düşünce hak eder. `Prisma`'dan geliyorsanız, kit Drizzle üzerinde standartlaşır — geçiş sırasında ürün tabloları için Prisma'yı tutabilirsiniz, ancak yakınsamayı planlayın; tek bir kod tabanında iki ORM, bileşik bir bakım vergisidir. [Prisma ve Drizzle karşılaştırması](https://supastack.dev/tr/blog/prisma-vs-drizzle-for-saas.md) neyin değiştiğini ortaya koyar.

Yönetilen bir auth sağlayıcısından geliyorsanız, geçişten önce her sağlayıcı özelliğini kopyalama dürtüsüne direnin. Yönetilen auth, ürününüzün kullanmayabileceği şeyleri sessizce paketler — oturum listeleri, organizasyon arayüzleri, webhook senkronizasyonu. Ürününüzün gerçekten çağırdıklarını eşleyin; [auth karşılaştırması](https://supastack.dev/tr/blog/better-auth-vs-nextauth-vs-clerk.md) önemli olan yetenek farklarını kapsar.

| Mevcut tesisatınız | supastack modülü | Neler taşınır |
|---|---|---|
| NextAuth.js / Auth.js oturumları | Kimlik doğrulama (Better Auth) | Kullanıcılar ve hesaplar taşınır; oturumlar geçişte yeniden verilir |
| Clerk veya yönetilen bir auth sağlayıcısı | Kimlik doğrulama (Better Auth) | Kullanıcılar e-postayla taşınır; üçüncü taraf oturumlar yeniden oynatılmaz, terk edilir |
| Özel organizasyon/ekip tabloları | Çalışma Alanları | Organizasyon satırlarınız çalışma alanı + üyelik satırlarına dönüşür |
| El yapımı Stripe webhook'ları | Faturalandırma | Stripe müşteri ID'leri korunur; abonelik durumu yeniden türetilir |
| CRON + setTimeout işleri | İşler (Trigger.dev) | Zamanlanmış işler paylaşılan JobRunner sözleşmesinin arkasına taşınır |
| Nodemailer / plansız e-posta | E-posta | Şablonlar taşınır; gönderim tek bir sağlayıcı bağdaştırıcısından geçer |


## Modülleri bağımlılık sırasıyla benimseyin

Taşıma sırası bir tercih değildir — bir bağımlılık grafiğidir. Aşağıdaki her aşama ayrı ayrı yayınlanabilir ve her biri, bir sonraki başlamadan önce doğrulayabileceğiniz çalışan bir sistem üretir. Ayartı, her şeyi tek bir hafta sonunda yapıp kesişimi debug etmektir; direnin — aşamalı bir taşıma, karşılaştığınız her hatanın tam olarak bir modüle ait olduğu anlamına gelir; bu, ancak atladığınızda değerini anlayacağınız bir debug süper gücüdür.

- Aşama 1 — iskelet: kiti iskeletlendirin, env'i yapılandırın, ürün rotalarınızı proje yapısına yerleştirin. Henüz hiçbir şey bağlı değil; uygulama açılır ve sayfalarınız render edilir.
- Aşama 2 — auth: oturum açmayı Better Auth'a taşıyın, kullanıcı/hesap tablolarını taşıyın, giriş + çıkışı uçtan uca doğrulayın. Sonraki her aşama, bir oturumun var olmasına bağlıdır.
- Aşama 3 — kiracılık: çalışma alanı modelini benimseyin, ürün tablolarınıza `workspaceId` geri doldurun, okuma ve yazmalarda kapsamı zorunlu kılın. [Çalışma alanı sınırları yazısı](https://supastack.dev/tr/blog/workspace-boundaries.md) tam da burada değerini gösterir.
- Aşama 4 — faturalandırma: checkout ve webhook'ları faturalandırma modülüne yönlendirin, mevcut abonelikleri yeniden eşleyin, test modunda gerçek Stripe verilerine karşı entitlement denetimlerini doğrulayın.
- Aşama 5 — arka plan işleri ve e-posta: işleri JobRunner sözleşmesine taşıyın ve işlemsel e-postayı e-posta bağdaştırıcısına geçirin. Bunlar sondadır çünkü halihazırda var olan kullanıcılara ve çalışma alanlarına bağlıdır.


## Verileri dürüstçe taşıyın

Veri taşıma, taşımaların namını kazandığı yerdir. Sıkıcı kalmasını sağlayan kurallar: iki kez çalıştırabileceğiniz bir script yazın, geçişe kadar kaynağı asla değiştirmeyin ve scripte güvenmek yerine sayımları doğrulayın.

Kullanıcılar ve hesaplar Better Auth şemasına iner — e-posta birleştirme anahtarıdır ve parola tabanlı hesaplar bir karar gerektirir: ya mevcut hash formatınız Better Auth'un doğrulayabildiği bir formattır ya da geçişte bir parola sıfırlama akışı yayınlar ve bunu bir zorlayıcı işlev olarak ele alırsınız. Üçüncü taraf OAuth hesapları kolay durumdur — sağlayıcı onları bir sonraki girişte yeniden verir.

Faturalandırma için dürüst yol, satır kopyalamak yerine yeniden türetmedir: Stripe müşteri ID'sini koruyun, kitin webhook işlemesinin entitlement durumunu sağlayıcının doğrusundan yeniden kurmasına izin verin ve hesapladığını mevcut abonelik kayıtlarınızla karşılaştırın. Kitin [idempotent webhook defteri](https://supastack.dev/tr/blog/idempotent-billing-webhooks.md), tam da yeniden oynatılan tarihsel olayların hiçbir şeyi çift sağlamaması için vardır.

```
// migration scripts are boring by design: upsert-shaped,
// re-runnable, and they verify counts instead of trusting themselves
for (const legacyUser of legacyUsers) {
  await upsertAuthUser({
    email: legacyUser.email.toLowerCase(),
    name: legacyUser.displayName,
    externalId: legacyUser.id, // preserved for one-shot joins
  });
}
const migrated = await countAuthUsers();
if (migrated !== legacyUsers.length) {
  throw new Error(`count mismatch: ${migrated} of ${legacyUsers.length}`);
}
```


## Size ait kalanlar

Açıkça söylemeye değer, çünkü insanların iki yönde de yanlış anladığı kısım budur: ürün rotalarınız, şemanız, alan mantığınız ve tasarımınız değişmez. Uygulamanızı kitin içinde yeniden inşa etmiyorsunuz — onu kitin üstüne yerleştiriyorsunuz.

Ters yöndeki hata ise eski tesisatı yeni modülün yanında 'geçici olarak' canlı tutmaktır. İkinci bir oturum denetimi, ikinci bir webhook işleyicisi, ikinci bir entitlement tablosu — her 'geçici' paralel sistem, biri silene kadar kalıcıdır ve her biri gelecekteki bir olaydır. Değiştirin, doğrulayın, silin. Bir aşama eski yolu henüz silemiyorsa, bitmemiştir.


## Geçiş kontrol listesi

Geçiş bir olay değil, bir kontrol listesidir. Gerçek tarihten önce üretim biçiminde verilerle bir staging ortamında en az bir kez çalıştırın.

- Veri scriptini taze bir üretim anlık görüntüsüne karşı yeniden çalıştırın; sayımlar ve nokta kontrolleri geçsin.
- Ürününüzün desteklediği her auth sağlayıcısıyla giriş yapın — var olduğunu unuttuklarınız da dahil.
- Stripe test modunda kendi ürününüzü satın alın ve webhook'u entitlement'a kadar izleyin.
- Her işlemsel e-postayı bir kez gönderin; bağlantıların yeni dağıtıma düştüğünü kontrol edin.
- Ödeme yapan yolculuğu uçtan uca doğrulayın, ardından DNS/env'i çevirin ve ilk gerçek oturumu izleyin.
- Eski dağıtımı bir hafta çalışır durumda tutun — geri dönüş bir DNS değişikliğidir, taşıma değil.


## Bir başlangıç kitine geçiş hakkında sık sorulan sorular

Biri bu işe oturduğunda hep aynı birkaç soru gündeme gelir.

- Bir taşıma gerçekte ne kadar sürer? — Standart auth + Stripe'lı tek bir web uygulaması için: haftalar değil, akşamlardan oluşan günler. Özel faturalandırmalı çok kiracılı B2B, üçüncü ve dördüncü aşamalara zaman ekler — uzayan şey veri işidir, dosya taşıması asla değil.
- Taşımalı mıyım yoksa sıfırdan başlayıp özellikleri mi port etmeliyim? — Ürün kodunuz altyapı borcunuzdan küçükse, kitin üzerinde sıfırdan başlayıp ürün rotalarını taşımak genellikle daha hızlıdır. Şemanız ve alan mantığınız zor kısımsa, yerinde taşıyın.
- Geçiş sırasında mevcut ORM'imi / auth kütüphanemi tutabilir miyim? — Kısa süreliğine, evet — her seferinde bir modül sınırı. Kalıcı olarak, hayır: altyapı katmanında her şeyden iki tane olması bileşik bir vergidir.
- Peki ya halihazırda yolda olan Stripe webhook'larım? — Dördüncü aşama doğrulandıktan sonra mevcut webhook uç noktasını kitin işleyicisine yönlendirin; idempotent defter, yeniden oynatılan veya yinelenen olayları tehlikeli yerine güvenli kılar.
- Her modülü benimsemek zorunda mıyım? — Hayır. Mobil, masaüstü, işler ve AI, benimsenecek ya da yok sayılacak yüzeylerdir — lisans temeldir, platform başına bir uygulama yayınlama zorunluluğu değildir.