وردپرس یا طراحی سایت اختصاصی؟ مقایسه هزینه، ریسک و Fit

پاسخ سریع بر اساس نوع پروژه

این انتخاب دو گزینه ندارد؛ پنج پله دارد

۱. سایت‌ساز میزبانی‌شده

برای معرفی ساده، Landing یا اعتبارسنجی ایده، Builder می‌تواند سریع‌ترین گزینه باشد. اما Export، دسترسی به کد/داده، SEO فنی، هزینه مبتنی بر Plan و امکان اتصال باید پیش از خرید آزموده شود. مقایسه کامل این مسیر در راهنمای سایت‌سازهای هوش مصنوعی، TCO و خروج آمده است.

۲. وردپرس پیکربندی‌شده

هسته، Theme و تعداد کمی افزونه معتبر بدون تغییر عمیق. این پله برای Content، Marketing و فرایندهای رایج مناسب است. سرعت تحویل خوب است، اما Governance افزونه، Staging و Patch همچنان لازم‌اند.

۳. وردپرس با Theme یا Plugin اختصاصی

CMS و Workflow تحریریه حفظ می‌شود، اما Capability متمایز در Plugin/Block اختصاصی پیاده می‌گردد. این گزینه غالباً از «صد افزونه» یا «بازنویسی همه‌چیز» بهتر است؛ به‌شرط آنکه منطق دامنه از Theme جدا، API/Schema تعریف و تست خودکار وجود داشته باشد.

۴. معماری Hybrid یا Headless

WordPress ممکن است منبع محتوای Editorial باشد و Frontend یا Core transaction جدا اجرا شود. REST API رسمی WordPress دسترسی ساختاریافته به محتوا و توسعه Client جدا را ممکن می‌کند. این انعطاف هزینه Cache invalidation، Preview، Authentication، Search، Deployment و Observability دو سامانه را اضافه می‌کند.

۵. اپلیکیشن اختصاصی

Framework، کتابخانه و سرویس‌های استاندارد استفاده می‌شوند، اما Domain model، Workflow، API و UI برای مسئله شما ساخته می‌شوند. «اختصاصی» نباید به معنی بازنویسی رمزنگاری، Auth، Queue، Search یا Admin از صفر باشد. Build-versus-buy برای هر Capability جداست.

پیش از مقایسه، «طراحی اختصاصی» را در قرارداد تعریف کنید

دو پیشنهاد ممکن است هر دو «اختصاصی» نامیده شوند اما یکی فقط ظاهر سفارشی روی WordPress باشد و دیگری نرم‌افزار کامل. برای Quote هم‌سطح، این لایه‌ها را مشخص کنید:

اگر پیشنهاد فقط «طراحی اختصاصی ۳۰ صفحه» می‌گوید، هنوز معماری یا محصول را تعریف نکرده است. صفحه واحد هزینه نیست؛ Template، Component، State، Rule، Role، Integration و Migration محرک واقعی‌اند.

از Feature list به قرارداد نیاز برسید

در Discovery، هر نیاز را با این قالب بنویسید:

Actor + Job + Trigger
Current baseline + Pain evidence
Rule / Data / State / Exception
Volume + Peak + Freshness + SLO
Outcome + Guardrail + Acceptance test
Owner + Change frequency + Legal/Security class

مثلاً «باشگاه مشتریان» Feature نیست. آیا کاربر امتیاز می‌بیند؟ امتیاز از ERP می‌آید؟ قابل برگشت است؟ چند سطح و تاریخ انقضا دارد؟ در Refund چه می‌شود؟ چه کسی اختلاف را حل می‌کند؟ وقتی این Contract روشن شود، ممکن است افزونه استاندارد Fit باشد یا آشکار شود که Domain logic اختصاصی لازم است.

نشانه‌های نیاز استاندارد

• Content type و Workflow تحریریه رایج‌اند.
• نقش‌ها به Admin/Editor/Author/Customer نزدیک‌اند.
• قیمت، مالیات، ارسال، کوپن و Checkout استثنای محدود دارند.
• Integrationها مستند، پایدار و کم‌تعدادند.
• بار و SLO با Cache/CDN و Hosting متعارف پوشش داده می‌شود.

نشانه‌های منطق متمایز

• قیمت یا دسترسی تابع مشتری، قرارداد، شعبه، اعتبار و Approval است.
• Workflow چندمرحله‌ای با State، SLA، Escalation و Audit دارد.
• داده حساس، چند Tenant، Realtime، Offline یا Correctness سخت دارید.
• چند کانال از یک API و Source of truth مشترک استفاده می‌کنند.
• تغییر Capability هسته مزیت رقابتی است و هر ماه رخ می‌دهد.

مقایسه وردپرس و سایت اختصاصی؛ نه با شعار، با Trade-off

هزینه را با TCO سه‌ساله مقایسه کنید، نه قیمت روز اول

TCO36 = Discovery + Design + Build + Content/Migration
      + Hosting/CDN/Email/Search/Storage
      + Licenses/Plugins/SaaS/Usage/FX
      + Maintenance + QA + Security + DevOps + Support
      + Change demand + Downtime/Incident expected loss
      + Exit/Export/Replatform - Reusable asset value

در ایران، عدد ثابت خیلی زود کهنه می‌شود. مدل را با Driver بسازید: Role-day، تعداد Template و Integration، Catalog size، Order/Request volume، Peak، Release/month، Support hour، نرخ ارز و Renewal. برای هر Driver بازه Low/Likely/High و تاریخ قیمت بگذارید. روش ساخت Estimate و مقایسه Quote در راهنمای برآورد هزینه طراحی سایت آمده است.

اقلامی مثل جلسه، QA، مانیتورینگ، تمدید، مهاجرت و زمان خرابی معمولاً از Quote اولیه حذف می‌شوند؛ Cost register مقاله هزینه‌های پنهان سایت این بخش را کامل می‌کند.

زمان را در سه نقطه بسنجید

1. Time to first value: چند روز/هفته تا اولین Journey قابل استفاده؟
2. Lead time for change: از درخواست تا Production چند روز است؟
3. Recovery time: از شکست Release تا بازگشت سرویس چقدر؟

وردپرس می‌تواند شروع را کوتاه کند، اما اگر هر تغییر در Page Builder و چند افزونه Regression بسازد، Lead time بلند می‌شود. Custom می‌تواند Release pipeline سریع داشته باشد، اما فقط با Automated test، محیط‌ها و Ownership روشن. جدول زمان پیشنهادی Vendor بدون WBS، Dependency و Acceptance ارزش تصمیم ندارد.

امنیت: WordPress ناامن نیست و Custom خودکار امن نمی‌شود

سطح حمله WordPress شامل Core، Theme، Plugin، Admin، Hosting و Supply chain است. سطح حمله Custom شامل کد اختصاصی، Dependencyها، CI/CD، API، Cloud، Secret، Admin و Business logic می‌شود. در هر دو، احتمال × اثر × قابلیت کشف را بسنجید.

راهنمای رسمی Hardening WordPress امنیت را فرایندی پیوسته و نیازمند نسخه‌های به‌روز، Host قابل اعتماد، مجوز فایل، Backup و حفاظت دسترسی می‌داند. مستند به‌روزرسانی خودکار Theme و Plugin نیز Backup و مدیریت Update را لازم می‌داند؛ Auto-update جای Staging و Rollback را برای مسیرهای درآمدی نمی‌گیرد.

برای Custom، Requirement امنیت باید از طراحی وارد شود. OWASP ASVS می‌تواند مبنای قابل آزمون قرارداد امنیت باشد؛ «از آخر Pentest می‌گیریم» جای Secure SDLC را نمی‌گیرد. برای WordPress نیز راهنمای آپدیت امن، Staging و Rollback را در Operating model قرار دهید.

سرعت و مقیاس: نام پلتفرم KPI نیست

سایت اختصاصی می‌تواند Queryهای N+۱، JavaScript سنگین و Cache ناقص داشته باشد؛ WordPress نیز می‌تواند با Theme سبک، Object/page cache، CDN، تصاویر مناسب و Query سالم سریع باشد. تصمیم را با Journey و Budget بسنجید:

• Traffic معمول و Peak، نسبت Anonymous/Logged-in و Cacheability
• Catalog/Content size، Search/filter، Write rate و Freshness
• P75 LCP/INP/CLS در Mobile واقعی و شبکه کاربران ایران
• TTFB، Cache hit، Database time، Error rate و Saturation
• Checkout/Login/API latency و Correctness، نه فقط صفحه خانه
• Load test با Dataset و Dependency نزدیک Production

بودجه Performance و RUM برای هر دو معماری لازم است. روش اندازه‌گیری Field و جلوگیری از Regression در راهنمای Core Web Vitals، LCP، INP و CLS آمده است.

محتوا و SEO؛ هزینه Admin را دست‌کم نگیرید

WordPress فقط Renderer نیست؛ Draft، Revision، Media، Taxonomy، Preview، Schedule، Role، Embed و API تحریریه را آماده می‌دهد. در Custom باید تصمیم بگیرید این Capabilityها Build، Buy یا حذف شوند. یک پنل با دو Textarea «CMS کامل» نیست.

برای WordPress، انتخاب Gutenberg، Block Theme، Classic Theme یا Page Builder روی Performance و قابلیت خروج اثر دارد؛ مقاله گوتنبرگ، FSE و معماری ویرایش این تصمیم را پوشش می‌دهد.

مالکیت را با «فایل زیپ» اشتباه نگیرید

WordPress تحت GPLv2 یا بالاتر منتشر می‌شود و آزادی استفاده، مطالعه، تغییر و توزیع را فراهم می‌کند؛ اما این واقعیت به‌تنهایی مالکیت دامنه، حساب Host، License افزونه تجاری، Design asset، داده مشتری یا دسترسی Repository را حل نمی‌کند. در Custom نیز پرداخت فاکتور لزوماً Assignment حقوق کد یا تحویل Source نیست.

Asset register تحویل

• دامنه، Registrar، DNS، CDN، TLS و ایمیل
• Hosting/Cloud، Billing owner، Backup و Logs
• Repository، Branch protection، CI/CD و Artifact registry
• Database schema، Data dictionary، Export و Retention
• Theme/Plugin/Font/Image/Code license و Renewal
• Analytics، Search Console، Tag manager، PSP، SMS و CRM accounts
• Design system، Source file، Content inventory و URL map
• Runbook، Architecture decision record و Vendor contact

Exit test، نه Exit clause

یک Export نمونه را روی محیط مستقل Restore کنید. در WordPress بررسی کنید Posts، Custom fields، Taxonomy، Media، User mapping و Redirectها بیرون می‌آیند؛ Shortcode/Page-builder blob می‌تواند قابل حمل نباشد. در Custom، Build از Repository تازه، Infrastructure، Seed data، Secret injection و Migration را تمرین کنید. اگر فقط Vendor قادر به راه‌اندازی است، مالکیت عملی ندارید.

Integration پرریسک را پیش از انتخاب پلتفرم نمونه‌سازی کنید

بسیاری از پروژه‌ها نه در صفحه، بلکه در اتصال ERP، موجودی، قیمت، ارسال، پیامک یا پرداخت شکست می‌خورند. پیش از قرارداد اصلی یک Vertical slice بسازید:

real SKU/customer fixture
→ read inventory and customer-specific price
→ create cart/order with idempotency key
→ redirect to payment sandbox
→ verify callback/webhook server-side
→ write ERP result / handle timeout
→ reconcile order and expose support evidence

Contract شامل Source of truth، Auth، Timeout، Retry، Idempotency، Rate limit، Error taxonomy، PII، Audit، Reconciliation و Sandbox است. اگر API طرف مقابل ناپایدار باشد، Custom بودن Frontend آن را درمان نمی‌کند. گاهی Anti-corruption layer یا Integration service جدا بهترین مرز است.

چه زمانی Hybrid بهتر از مهاجرت کامل است؟

اگر Content/SEO بالغ است اما یک Workflow محصولی ویژه دارید، «Strangler» ریسک کمتری از Big-bang دارد:

mindio-example.ir       → WordPress: content, landing, docs
app.mindio-example.ir   → Custom app: authenticated workflow
api.mindio-example.ir   → Domain services and integrations

shared contracts: identity handoff, design tokens, analytics,
consent, canonical URLs, navigation, incident/status ownership

اما Hybrid هزینه واقعی دارد: SSO، Cookie/CORS، Preview، Search، Cache invalidation، Analytics attribution، Deployment و Support چند تیم. اگر تنها دلیل آن «مدرن بودن Headless» است، نروید. معماری و مدل مهاجرت کامل در راهنمای Headless و Hybrid بررسی شده است.

اگر WordPress انتخاب شد: اکوسیستم افزونه را اداره کنید

برای هر افزونه Owner، Version policy، Change window و Replacement plan داشته باشید. افزونه غیرفعال اما نصب‌شده نیز Code سطح حمله است. Pluginهای Production را با Composer/manifest یا حداقل Inventory نسخه‌دار نگه دارید؛ تغییر مستقیم فایل Core/Plugin ممنوع باشد.

اگر Custom انتخاب شد: تیم نگهداری بخشی از محصول است

سایت اختصاصی پروژه‌ای نیست که روز تحویل تمام شود. حداقل نقش‌ها و مسئولیت‌ها را مشخص کنید؛ یک نفر ممکن است چند نقش داشته باشد، اما مسئولیت نباید گم شود:

• Product owner برای Outcome، Scope و Backlog
• Tech lead برای Architecture، review و debt
• Frontend/Backend برای Build و automated tests
• QA برای Journey، regression، device و accessibility
• DevOps/SRE برای deploy، backup، monitoring، capacity و incident
• Security/Privacy owner برای threat model، patch و data lifecycle
• Content/SEO owner برای schema، URL، redirect و editorial workflow

Bus factor، زمان On-call، تعطیلات، جانشینی Vendor و Knowledge transfer را در TCO بگذارید. اگر سازمان نمی‌تواند Release ماهانه، Patch اضطراری و Restore drill را اداره کند، Custom ممکن است کنترل نظری بدهد اما ریسک عملی را بیشتر کند.

نسخه ایران؛ نیازهایی که Demo خارجی نشان نمی‌دهد

راه دورزدن محدودیت Provider بخشی از معماری پایدار نیست. گزینه‌ای انتخاب کنید که Eligibility و پشتیبانی قانونی/عملی آن برای سناریوی شما روشن باشد و مسیر Export مستقل داشته باشد.

کیفیت مشترک هر دو گزینه

پلتفرم، Accessibility را تضمین نمی‌کند. Acceptance را بر Journeyهای واقعی و مرجع WCAG 2.2 بسازید: Keyboard، Focus، Label/Error، Contrast، Zoom/Reflow، Screen reader، Reduced motion و Touch target. Theme آماده ممکن است مشکل داشته باشد؛ Component اختصاصی نیز اگر Semantics نداشته باشد بدتر است.

Definition of Done مشترک:

• Unit/Integration/E2E برای Ruleهای بحرانی
• Responsive/RTL/Browser/Device matrix
• Accessibility automated + manual keyboard/screen-reader sampling
• Performance budget و RUM
• Security acceptance و Dependency scan
• SEO crawl، canonical، schema، sitemap و redirect
• Backup/restore، rollback و incident drill
• Content/admin training و Handover evidence

ماتریس تصمیم وزن‌دار بسازید

وزن را پیش از دیدن Demo Vendor تعیین کنید تا نتیجه با جذابیت ارائه جابه‌جا نشود. امتیاز ۱ تا ۵ را فقط با Evidence بدهید.

Security، Legal/Eligibility، Data correctness و Exit را Knockout کنید: گزینه‌ای که حداقل را رد می‌کند با امتیاز زیبایی یا قیمت جبران نشود.

پیشنهادهای Vendor را هم‌سطح کنید

یک RFP کوچک و Evidence-based بفرستید:

1. Outcome، کاربران، Journeyها و Baseline
2. Scope in/out و Assumptionها
3. Data/Role/Integration/Volume/SLO/Compliance
4. Option architecture و Trade-off ثبت‌شده
5. Deliverable، Acceptance، Owner و Milestone
6. قیمت Setup/Recurring/Variable/Change/Risk/Exit
7. Team/CV/availability/Bus factor و Subcontractor
8. Security، QA، Deployment، Support و Incident
9. IP/license/accounts/repository/data/exit clauses
10. Vertical slice پولی کوچک پیش از Commit اصلی

«نامحدود»، «امن»، «سئو کامل»، «سرعت عالی» و «مالکیت صددرصد» بدون Test و Boundary امتیاز نمی‌گیرند. Reference مشتری را درباره Upgrade، Incident، Change quote و Exit بپرسید، نه فقط رضایت از ظاهر.

Discovery دوهفته‌ای و Vertical slice؛ تصمیم فناوری را خروجی کنید

روزهای ۱ تا ۳: مسئله و Baseline

Journey، KPI، داده، نقش، Pain، حجم، Current cost و Constraints را ثبت کنید. راه‌حل از پیش تعیین‌شده وارد جلسه نشود.

روزهای ۴ تا ۶: Option و Knockout

Builder، WordPress standard/custom، Hybrid و Custom را روی Fit، تیم، امنیت، TCO و Exit مقایسه کنید. پیچیدگی غیرضروری را حذف کنید.

روزهای ۷ تا ۹: Vertical slice پرریسک

سخت‌ترین Integration یا Workflow را با داده نزدیک واقعیت بسازید؛ Happy path تنها کافی نیست. Timeout، Duplicate، Permission، RTL و Error recovery را آزمایش کنید.

روزهای ۱۰ تا ۱۲: Operations و Quality

Deploy، Rollback، Patch، Backup/Restore، RUM، Accessibility، Support و Handover را روی نمونه تمرین کنید.

روزهای ۱۳ و ۱۴: Investment gate

Architecture decision record، WBS، TCO range، Risks، Acceptance و Exit را تحویل دهید. اگر Evidence کافی نیست، Pilot را محدود تمدید کنید؛ Scope بزرگ را با حدس امضا نکنید.

پنج مثال نزدیک به بازار ایران

شرکت خدمات حرفه‌ای با تیم محتوا

WordPress با Block/Pattern کنترل‌شده، CRM form integration و Governance افزونه معمولاً Fit است. پنل اختصاصی ارزش کمی دارد؛ بودجه را روی محتوا، Performance، Conversion و Analytics بگذارید.

فروشگاه با ۳۰۰۰ کالا و فرایند رایج

WooCommerce می‌تواند گزینه شروع باشد، اگر Sync موجودی، Cache، Checkout، Payment reconciliation و عملیات Update آزموده شود. «۳۰۰۰ کالا» به‌تنهایی دلیل Custom نیست؛ Query pattern و Order peak مهم‌اند.

پخش B2B با قرارداد قیمت و اعتبار

اگر هر مشتری لیست قیمت، شعبه، سقف اعتبار، تأیید فروش و ERP source of truth دارد، Plugin stacking احتمالاً بدهی می‌سازد. Custom domain service با WordPress برای Content یا Headless storefront قابل بررسی است.

کلینیک با معرفی پزشک و رزرو

سایت محتوایی می‌تواند WordPress باشد؛ رزرو و داده حساس را به سرویس تخصصی یا App جدا با Access، Audit و Retention مشخص بسپارید. اتصال ساده‌تر از نگه‌داری داده پزشکی در Custom post type عمومی است.

استارتاپ در جست‌وجوی Product-market fit

Landing و Content را سریع با WordPress/Builder بسازید و Core hypothesis را با Prototype جدا آزمایش کنید. بازنویسی بعد از یادگیری ممکن است ارزان‌تر از Foundation سنگین قبل از شناخت مسئله باشد.

چهار Runbook مستقل از انتخاب فناوری

Release شکست خورد

1. Deployment را متوقف و Owner تعیین کنید.
2. Error، Journey و تغییر مرتبط را ثبت کنید.
3. Rollback/feature flag را طبق RTO اجرا کنید.
4. Data migration را جدا Reconcile کنید.
5. Root cause و Regression test اضافه کنید.

آسیب‌پذیری بحرانی اعلام شد

1. Inventory و Exposure را مشخص کنید.
2. Exploitability/impact را Triage و Mitigation موقت اعمال کنید.
3. Patch را در Staging و Journeyهای بحرانی تست کنید.
4. Deploy، Monitor و credential/key rotation لازم را انجام دهید.
5. Evidence و SLA را ثبت کنید.

Backup باید Restore شود

1. RPO/RTO و Last known good را تعیین کنید.
2. Backup را در محیط ایزوله Verify کنید.
3. Files/DB/config/secrets و external state را هماهنگ بازگردانید.
4. Smoke test و Reconciliation انجام دهید.
5. DNS/traffic را برگردانید و Postmortem بنویسید.

Vendor یا سرویس باید عوض شود

1. Asset register، Contract و Export را Freeze/Snapshot کنید.
2. Data/Media/URL/Account/License dependency را Map کنید.
3. Rebuild/Restore را روی مقصد تمرین کنید.
4. Migration را Canary و Redirect/Reconciliation را اجرا کنید.
5. دسترسی قدیمی را Revoke و Retention/Deletion evidence بگیرید.

Backup بدون Restore test فقط امید است. RPO/RTO، نسخه‌های Immutable و تمرین کامل در راهنمای بازیابی فاجعه و Backup سایت آمده است.

هفت گزاره‌ای که نباید مبنای تصمیم باشند

• «WordPress فقط برای سایت کوچک است»: بار، معماری، Cache، Query، افزونه و عملیات تعیین‌کننده‌اند.
• «Custom همیشه سریع‌تر است»: Performance نتیجه Budget، طراحی و اندازه‌گیری است.
• «WordPress مالکیت ندارد»: Core آزاد است؛ Lock-in می‌تواند در Builder/Plugin/Host/Contract باشد.
• «Custom مالکیت کامل می‌دهد»: بدون Source، License، account، docs و rebuild test خیر.
• «افزونه یعنی بدون هزینه»: Evaluation، License، update، compatibility، support و exit هزینه دارند.
• «Headless سئو را بهتر می‌کند»: Rendering، metadata، URL، crawl و performance باید درست ساخته شوند.
• «بعداً امنیت و دسترس‌پذیری اضافه می‌کنیم»: دیرکرد، بازکاری و نقص ساختاری می‌سازد.

چک‌لیست نهایی Go/No-go

• Outcome، Baseline، کاربران و سخت‌ترین Journey شواهد دارند.
• نیاز استاندارد از منطق متمایز جدا شده است.
• پنج پله Builder/WordPress/WordPress custom/Hybrid/Custom مقایسه شده‌اند.
• Quoteها Scope، Deliverable و Acceptance هم‌سطح دارند.
• TCO سه‌ساله Setup/Recurring/Variable/People/Risk/Exit را پوشش می‌دهد.
• امنیت، Privacy، Accessibility، Performance و SEO معیار آزمون دارند.
• WordPress plugin governance یا Custom SSDLC/operations بودجه دارد.
• مالکیت Repository/Data/Domain/Accounts/License و Exit test روشن است.
• ریال/تومان، جلالی، RTL، فارسی، پرداخت، پیامک و شبکه ایران تست شده‌اند.
• Vertical slice پرریسک و Failure path پیش از Commit اصلی اجرا شده است.
• Release، Patch، Restore و Vendor-exit Runbook Owner دارند.

سؤالات متداول وردپرس یا طراحی اختصاصی

وردپرس بهتر است یا سایت اختصاصی؟

برای Content، سایت شرکتی و فروش استاندارد، WordPress معمولاً سریع‌تر و اقتصادی‌تر است. برای Workflow، نقش، داده و Integration متمایز، Custom یا Hybrid ممکن است Fit بهتری داشته باشد. پاسخ با نیاز و توان عملیات تعیین می‌شود، نه نام فناوری.

آیا سایت اختصاصی برای سئو بهتر است؟

خودکار خیر. هر دو می‌توانند URL، Canonical، Schema، Sitemap، Performance و Editorial workflow خوب یا بد داشته باشند. در Custom باید Capabilityهای SEO/Admin را صریح بسازید؛ در WordPress خروجی Theme/Pluginها را کنترل کنید.

آیا وردپرس امن نیست؟

WordPress به‌خاطر گستردگی هدف پرتکراری است، اما Core/Theme/Plugin به‌روز، افزونه حداقلی، MFA، Least privilege، WAF، Backup، Monitoring و Incident process امنیت قابل دفاع می‌سازند. Custom نیز بدون Secure SDLC می‌تواند آسیب‌پذیرتر باشد.

هزینه طراحی اختصاصی چقدر بیشتر است؟

ضریب ثابت معتبری وجود ندارد. Scope، Integration، Role، داده، QA، SLO و تیم نگهداری تعیین‌کننده‌اند. Low/Likely/High سه‌ساله بسازید و WordPress سفارشی‌شده را با Custom هم‌سطح مقایسه کنید.

آیا می‌توان از وردپرس به سایت اختصاصی مهاجرت کرد؟

بله، اما Data/Media/Taxonomy/Custom field/User، URL و Redirect، SEO metadata و Integration باید Map شوند. Shortcode و Page-builder content ممکن است تبدیل بخواهد. مهاجرت تدریجی و Reconciliation از Big-bang امن‌تر است.