مهاجرت از سایت‌ساز؛ تصمیم، داده، SEO و Cutover

ممکن است سایت جدید در روز Cutover کاملاً بالا بیاید، اما سفارش‌های ساعات آخر، URL تصاویر، رضایت‌های بازاریابی یا وضعیت پرداخت در آن نباشد. این مهاجرت از نظر فنی «موفق» و از نظر کسب‌وکار شکست‌خورده است. خطر اصلی Replatforming کمبود Animation یا Framework مدرن نیست؛ ناشناخته‌بودن Capability، داده، State و مسئولیت‌هایی است که پلتفرم قبلی برای شما انجام می‌داد.

مهاجرت از سایت‌ساز به پلتفرم جدید وقتی توجیه دارد که یک Gap اثبات‌شده، Outcome مهم را محدود کند و گزینه Extend/Integrate/Switch کم‌ریسک‌تر نباشد. این راهنما از Decision و TCO تا Export rehearsal، Data mapping، URL/SEO، Security، تست، Cutover، Rollback و پایش پس از Launch را پوشش می‌دهد—با ملاحظات فارسی، پرداخت، پیامک و شبکه ایران.

مهاجرت مرحله طبیعی رشد نیست

سایت‌ساز SaaS، فروشگاه Hosted، CMS متن‌باز، Headless و Custom code ابزارهایی با Boundary متفاوت‌اند؛ هیچ‌کدام مرحله بالاتر تکامل دیگری نیست. یک Builder مدیریت Hosting، Patch، Availability و بخشی از Security را کم می‌کند. پلتفرم Custom آزادی می‌دهد، اما Product discovery، Architecture، Accessibility، Security، Backup، Monitoring و On-call را به تیم شما منتقل می‌کند.

طیف راه‌حل؛ Build یا Nothing نیست

گاهی بهترین پاسخ، نگه‌داشتن Checkout روی Platform و ساخت Portal یا Configurator جداست. گاهی تغییر Hosted provider کم‌ریسک‌تر از ساخت Commerce engine است. «اختصاصی» را به Boundary دقیق تبدیل کنید: کدام Capability واقعاً Build می‌شود و چه سرویس‌هایی Buy/Managed می‌مانند؟

Decision contract؛ چه زمانی مهاجرت موجه است؟

Triggerهای معتبر

• Capability حیاتی با API/App/Workflow قابل‌حل نیست یا Risk غیرقابل‌قبول دارد؛
• Data portability، retention، audit یا residency شرط قراردادی/عملیاتی را نمی‌گذراند؛
• Limit مستند و آزموده‌شده SLO/Capacity را می‌شکند؛
• Unit economics با حجم واقعی و TCO گزینه دیگر بهتر است؛
• Integration حیاتی به‌دلیل Rate limit، Event gap یا State model غیرممکن است؛
• تیم توان پذیرش Security/Operations/Recovery را دارد.

Triggerهای ضعیف

• «سایت شبیه Template است» بدون آزمون Brand/Task؛
• انتخاب Framework مد روز؛
• یک Plugin یا Theme بد که قابل‌جایگزینی است؛
• ادعای کلی «SEO سایت‌ساز ضعیف است» بدون Crawl/Index evidence؛
• عدد بازدید بدون Workload/limit؛
• تصور اینکه Custom هزینه Subscription را حذف می‌کند.

Business case و TCO کامل

Migration TCO =
Discovery + Design + Build/Buy + Data/Content migration
+ Integration + Security + Accessibility + SEO + QA
+ Parallel run + Cutover + Training + Support
+ Hosting/Observability/Backup/On-call/Maintenance
+ Change/Incident/Compliance/Exit over the decision horizon

قیمت را به «چند صفحه» تقلیل ندهید. Complexity از Domain rule، داده تاریخی، Integration، نقش/مجوز، Transaction، Migration window و SLO می‌آید. نرخ ارز، سرویس خارجی، Payment، SMS، CDN و نیروی متخصص ایران را در سناریوهای کم/محتمل/زیاد بیاورید.

Inventory؛ چیزی را که نمی‌شناسید منتقل نمی‌کنید

Inventory را فقط از Admin menu نسازید. API، Export، webhook، sitemap، crawl، analytics، server/CDN log، Search Console، Finance reconciliation و مصاحبه با اپراتور را کنار هم بگذارید. Shadow processهای Excel/Telegram و اصلاح دستی سفارش نیز بخشی از سیستم واقعی‌اند.

Export rehearsal؛ قبل از قرارداد جدید

«قابل Export» به معنی «قابل بازسازی» نیست. Format ممکن است ID، رابطه، تاریخچه، فایل، custom field یا State لازم را نداشته باشد. برای نمونه، راهنمای رسمی Export سفارش Shopify توضیح می‌دهد CSV تاریخچه سفارش، داده تاریخی زمان سفارش را نشان می‌دهد و Authorization در Transaction export نیست؛ Product CSV نیز Schema و محدودیت‌های خودش را دارد. این مثال عمومی است: Export هر Provider را با نمونه واقعی و تاریخ تصمیم آزمون کنید.

1. یک Full export و یک API sample بگیرید؛
2. Schema، ID، relationship، encoding و timezone را Profile کنید؛
3. Pagination، rate limit، deleted/archived و media URL را تست کنید؛
4. Count/hash/amount/status را با Source reconcile کنید؛
5. Delta export یا webhook gap را بسنجید؛
6. Import به Target sandbox و round-trip sample اجرا کنید؛
7. زمان، هزینه، خطا و Manual exception را ثبت کنید؛
8. Exit pack را پیش از وابستگی بیشتر ذخیره و مستند کنید.

قرارداد Reconciliation

Completeness = migrated eligible records / source eligible records
Financial reconciliation = Σ order/refund/payment amounts by currency/status/day
Referential integrity = valid child references / total child references
Media integrity = reachable and checksum-matched assets / expected assets
URL coverage = mapped old public URLs / eligible old public URLs

Count برابر می‌تواند داده اشتباه داشته باشد؛ Sample semantic، Hash و Aggregate مالی لازم‌اند. رکورد Quarantineشده Owner و Resolution deadline داشته باشد. Migration script باید Idempotent، versioned، observable و قابل تکرار باشد.

Data mapping؛ Column به Column کافی نیست

Password را plaintext صادر یا منتقل نکنید. اگر Hash/algorithm قابل‌انتقال امن نیست، Password reset و Session revocation را به‌عنوان Journey طراحی کنید. داده منقضی یا بدون Purpose را صرفاً «برای احتیاط» کپی نکنید؛ Legal/privacy review باید با قوانین و قراردادهای جاری انجام شود.

Target platform را از Business contract بسازید

Backlog «همه‌چیز مثل قبل + بهتر» قابل‌آزمون نیست. برای هر Capability این فیلدها را بنویسید:

Parity به معنی بازسازی تمام quirks نیست. Must preserve، Improve، Retire و Defer بسازید. Capability بازنشسته‌شده باید Impact، Redirect/communication و data retention plan داشته باشد.

API و Integration؛ مرزهای واقعی پلتفرم

Gateway، SMS، Email، CRM، ERP، Search، Analytics و Marketplace هرکدام Contract و Failure مستقل دارند. راهنمای طراحی API با قرارداد، امنیت و قابلیت اطمینان Version، Idempotency، Retry، Webhook، Error و Observability را پوشش می‌دهد.

• Webhook delivery را At-least-once فرض و handler را Idempotent طراحی کنید؛
• Backfill API و Live event بین Snapshot و Cutover Gap نداشته باشند؛
• Out-of-order event و replay آزمایش شود؛
• Payment callback با Server verification و reconciliation بسته شود؛
• Rate limit، timeout، retry budget و DLQ مشخص باشند؛
• Secret rotation و sandbox/production separation قبل از Launch اجرا شوند.

Custom یعنی پذیرش Security و Operations

پلتفرم قبلی ممکن است Runtime، Patch، DDoS، Backup، Fraud tooling یا Availability را مدیریت کرده باشد. در Target برای Infrastructure، OS، Runtime، Dependency، Code، IAM، Secret، Data، Backup، Monitoring و Incident یک RACI صریح بسازید.

OWASP ASVS برای Requirementهای قابل‌آزمون Application security و NIST SSDF برای Practiceهای توسعه امن مرجع‌های مناسبی‌اند؛ Compliance خودکار نیستند و باید براساس Scope/Risk انتخاب شوند. برای API/OAuth/JWT نیز راهنمای امنیت API و OWASP را ببینید.

SEO migration؛ ابتدا URL را حفظ کنید

تعویض CMS الزاماً به تغییر URL نیاز ندارد. اگر Information architecture و Intent عوض نمی‌شود، حفظ Host/path/query semantics ریسک و هزینه Crawl را کم می‌کند. وقتی URL باید عوض شود، Mapping باید از Sourceهای متعدد ساخته شود: sitemap، crawl، CMS export، server/CDN log، Analytics، Search Console، backlink و media inventory.

راهنمای رسمی Google برای Site move توصیه می‌کند تغییرها را در صورت امکان یکی‌یکی انجام دهید، Mapping دقیق بسازید، Redirect دائمی سمت سرور را مستقیم به مقصد نهایی بدهید، internal link/canonical/hreflang/sitemap را به URL جدید به‌روز و هر دو سمت را مانیتور کنید. نوسان موقت ممکن است رخ دهد و سرعت پردازش به URL count و crawl capacity بستگی دارد؛ رشد رتبه تضمین‌شده نیست.

قرارداد URL و Annotation

• یک Old URL فقط یک مقصد نهایی و مرتبط داشته باشد؛
• Redirect chain/loop، mixed HTTP/HTTPS و slash variant حذف شوند؛
• Canonical جدید self-referencing و با Redirect/Sitemap/Internal link همسو باشد؛
• hreflang، pagination، structured data و OG URL به‌روز شوند؛
• Image/PDF/download و external high-value link فراموش نشوند؛
• Old redirect حداقل بازه توصیه‌شده Google—عموماً یک سال—و برای کاربر ترجیحاً بیشتر حفظ شود؛
• Change of Address فقط وقتی Domain عوض می‌شود و Propertyها تأیید شده‌اند؛
• New host ظرفیت Crawl اضافه ناشی از Redirect را داشته باشد.

برای Baseline و بازبینی Crawl/Index/Canonical/Schema/Link پس از Launch، چک‌لیست ممیزی کامل SEO مکمل اجرای Migration است.

Staging را امن و قابل‌آزمون نگه دارید

Staging عمومی با فقط robots.txt امن نیست؛ فایل robots مانع دسترسی کاربر یا مهاجم نمی‌شود و اگر Crawl را Block کند، موتور ممکن است noindex را نبیند. Authentication و Network/access control را لایه اصلی قرار دهید، Production secret و PII واقعی را کپی نکنید و در Launch checklist حذف Gate/noindex اشتباه را Machine-test کنید.

• داده Sanitized یا Synthetic؛
• Sandbox برای Payment/SMS/Email؛
• Domain/host allowlist و جلوگیری از ارسال واقعی؛
• Config/secret per environment؛
• Production-like schema/capacity و deploy pipeline؛
• Preview برای Content team بدون بازشدن عمومی.

UX و Accessibility را Regression نکنید

بازطراحی هم‌زمان با Replatforming دامنه علت را بزرگ می‌کند. اگر لازم نیست، Platform/Domain/Layout/Content را یکجا تغییر ندهید. Flowهای Login، Search، Form، Cart، Checkout، Account و Support را با Task و Acceptance مقایسه کنید؛ «ظاهر منحصربه‌فرد» Outcome نیست.

WCAG 2.2 Baseline جاری قابل‌استناد برای دسترس‌پذیری است. Keyboard/Focus، Name/Role/State، Error، Authentication، Target، Contrast، Reflow و Status را در Component و Journey تست کنید. داده migrated مثل Alt، Heading و Form label نیز باید Semantic خود را حفظ کند.

قرارداد فارسی و ایران

راهنمای طراحی فارسی از Locale تا RTL و QA Contract کامل‌تر متن، عدد، تاریخ و Bidi را ارائه می‌دهد. قانون، مجوز، مالیات، نگهداری داده و رضایت را با مشاور واجد صلاحیت و منابع جاری پروژه بررسی کنید؛ از Checklist عمومی به‌عنوان نظر حقوقی استفاده نکنید.

الگوی مهاجرت را براساس Coupling انتخاب کنید

Rollback کد با Rollback داده یکی نیست. وقتی کاربران در Target سفارش جدید ساخته‌اند، بازگشت DNS به Old platform بدون Reverse sync آن سفارش‌ها را گم می‌کند. برای Write، Roll-forward، compensation، dual-write محدود یا Freeze window را عمداً طراحی کنید.

Migration factory و Dry run

1. Snapshot نسخه‌دار Source بگیرید؛
2. Transform deterministic و Idempotent اجرا کنید؛
3. Target را از حالت تمیز بسازید؛
4. Import با checkpoint/quarantine انجام دهید؛
5. Count/hash/finance/relation/media/URL reconcile کنید؛
6. زمان هر Stage و Critical path را ثبت کنید؛
7. Delta از زمان Snapshot را اعمال کنید؛
8. Smoke/acceptance/load/security/SEO test اجرا کنید؛
9. Cleanup و تکرار تا Window هدف؛
10. Evidence pack و Go/No-go را امضا کنید.

اسکریپت یک‌بارمصرف بدون Log، version و retry در Cutover قابل اعتماد نیست. Fixture شامل فارسی، متن مختلط، media ناقص، سفارش refundشده، Variant حذف‌شده، user duplicate و timezone edge بسازید.

پشته آزمون پیش از Cutover

Performance را با «Lighthouse یک صفحه» نبندید؛ Field/Journey و Backend capacity را مقایسه کنید. راهنمای سرعت سایت، UX و Outcome Baseline، Budget و سنجش Production را تفکیک می‌کند.

Cutover runbook

Go/No-go و Kill criteria

• Critical data reconciliation خارج Threshold؛
• Payment/order/refund correctness مبهم؛
• Redirect/canonical/noindex/robots gate شکست؛
• Critical journey، Accessibility یا Security gate رد؛
• SLO/Capacity زیر Load نماینده پاس نشود؛
• Backup/restore/rollback یا Owner/escalation آماده نباشد؛
• Delta window از Cutover window عبور کند.

DNS، Domain و Email را فراموش نکنید

Cutover فقط A record نیست. Registrar access، DNSSEC، CAA، TLS، CDN origin، www/apex، IPv4/IPv6، MX/SPF/DKIM/DMARC، webhook allowlist و callback URL را Inventory کنید. DNS TTL را با زمان Cacheها و امکان Rollback واقع‌بینانه مدیریت کنید. راهنمای مدیریت DNS، TTL و مهاجرت دامنه Runbook دقیق این لایه را دارد.

Rollback، Backup و Decommission

Backup Source، Target، media، config، DNS و secret/reference را با Retention و encryption نگه دارید و Restore را تمرین کنید. راهنمای بازیابی فاجعه سایت و RPO/RTO Dataset و Drill را عمیق‌تر پوشش می‌دهد.

Old platform را روز بعد خاموش نکنید. Read-only access، export، redirect service، invoice/audit need و قرارداد Retention را نگه دارید. Decommission فقط پس از data/SEO/finance/support sign-off، Secret revocation، backup evidence و پایان window انجام شود.

Hypercare و پایش دوطرفه

هم Old و هم New را مانیتور کنید. راهنمای Observability وب‌سایت Signal را به Journey/SLO/Incident وصل می‌کند. Dashboard Migration حداقل این موارد را داشته باشد:

• Order/payment/refund/inventory reconciliation؛
• Login/reset/OTP/form/search/cart/checkout success؛
• 4xx/5xx، redirect hit، old URL traffic و broken asset؛
• Googlebot/crawler response، indexed old/new، sitemap/canonical؛
• Latency/error/saturation/queue/dependency؛
• Email/SMS/webhook delivery و retry/DLQ؛
• Support ticket/complaint و manual workaround؛
• Cost، cache، egress و provider quota.

پنجره‌های بررسی

چک‌لیست مهاجرت از سایت‌ساز

• Outcome و Capability gap با Evidence تعریف شده‌اند؛
• Configure/extend/integrate/switch/headless/custom مقایسه شده‌اند؛
• TCO شامل Build، Run، Change، Incident و Exit است؛
• RACI مسئولیت‌های منتقل‌شده از SaaS را پوشش می‌دهد؛
• Domain/DNS/URL/content/data/integration/operation inventory کامل است؛
• Full export و API/rate-limit/media/delta واقعاً Rehearse شده‌اند؛
• Data mapping برای ID/State/Time/Money/Text/Privacy/Password/Media دارد؛
• Migration script versioned، idempotent، observable و repeatable است؛
• Count/hash/finance/relation/media/URL reconciliation Gate دارند؛
• Must preserve/Improve/Retire/Defer روشن است؛
• API/webhook/payment idempotency/retry/replay تست شده‌اند؛
• Security، Accessibility، Performance و Operations Acceptance دارند؛
• URLها در صورت امکان حفظ و Mapping از چند Source ساخته شده است؛
• Redirect مستقیم مرتبط؛ ۴۰۴/۴۱۰ برای حذف واقعی؛ chain/loop صفر است؛
• Canonical/hreflang/internal link/sitemap/schema/media به‌روز شده‌اند؛
• Staging با Authentication و داده Sanitized محافظت می‌شود؛
• فارسی/RTL/ی‌ک/تومان‌ریال/زمان/شمسی/تلفن/آدرس تست شده‌اند؛
• چند Dry run در Window هدف با Exception owner اجرا شده‌اند؛
• Cutover، Go/No-go، Kill، rollback و write reconciliation آماده‌اند؛
• Old/New monitoring، Hypercare و Decommission gate تعریف شده‌اند.

جمع‌بندی؛ مهاجرت برنامه انتقال مسئولیت است

مهاجرت از سایت‌ساز فقط انتقال صفحه و تصویر نیست؛ انتقال Capability، داده، Identity، Transaction، URL، Integration و مسئولیت عملیاتی است. Custom می‌تواند Gap مهم را حل کند، اما Speed، SEO، Security و Scale را خودکار نمی‌سازد. اگر Business case و Team readiness وجود ندارد، Extend یا Hosted replacement می‌تواند تصمیم بهتر باشد.

پروژه قابل‌دفاع از Export rehearsal و URL/data contract شروع می‌شود، با Dry run و Reconciliation قابل‌تکرار می‌شود و در Cutover با Delta، Gate و Rollback کنترل می‌شود. موفقیت وقتی ثابت است که Order/Payment درست، Critical journey پایدار، Old URL قابل‌دسترسی، تیم پاسخگو و Benefit هدف در روزهای پس از Launch قابل‌اندازه‌گیری باشد.

سؤالات متداول مهاجرت از سایت‌ساز

چه زمانی از سایت‌ساز به پلتفرم اختصاصی مهاجرت کنیم؟

وقتی Capability حیاتی با تنظیم، App/API یا سرویس جدا حل نمی‌شود؛ Gap به Outcome/ریسک قابل‌اندازه‌گیری وصل است؛ TCO و Acceptance گزینه Target بهترند؛ و تیم توان Security، Operations و Recovery را دارد. ظاهر تکراری، بازدید بالا یا Framework جدید به‌تنهایی دلیل مهاجرت نیست.

آیا مهاجرت حتماً باعث افت سئو می‌شود؟

نوسان موقت در تغییر بزرگ ممکن است رخ دهد، اما شدت و مدت ثابت نیست. URL را تا حد ممکن حفظ کنید؛ Mapping دقیق، Redirect دائمی مستقیم، Canonical/Internal link/Sitemap هماهنگ، Crawl capacity و پایش Old/New لازم‌اند. Migration رشد رتبه را نیز تضمین نمی‌کند.

آیا همه داده‌های Wix، Shopify یا سایت‌ساز دیگر قابل انتقال‌اند؟

بدون Export rehearsal پاسخ عمومی ندارد. Content/Product/Customer/Order ممکن است CSV یا API داشته باشند، اما Theme، App state، payment authorization، history، custom field، relation یا password شاید کامل نباشد. نمونه واقعی Export کنید، Schema را Profile و Completeness/Finance/Relation/Media را Reconcile کنید.

مهاجرت چقدر زمان و هزینه می‌برد؟

عدد ثابت معتبر نیست. Scope Capability، حجم/کیفیت داده، URL count، Integration، Security/Accessibility، SLO، تعداد Dry run، Freeze/Delta و Team TCO را می‌سازند. ابتدا Discovery time-boxed و Export PoC انجام دهید و سپس low/base/high estimate با Contingency بسازید.

Big bang بهتر است یا مهاجرت مرحله‌ای؟

برای سایت کوچک با Write کم و Freeze ممکن، Big bang می‌تواند ساده‌تر باشد. برای Domainهای بزرگ و Coupling قابل‌تفکیک، Phased/Strangler ریسک را محدود می‌کند اما Dual state و routing می‌سازد. با Data consistency، URL/session، Cutover window و rollback evidence انتخاب کنید.