انتقال فروشگاه از سایت‌ساز؛ هزینه و چک‌لیست مهاجرت

چه زمانی انتقال از سایت‌ساز ارزش بررسی دارد؟

اول مشکلی را بنویس که با امکانات فعلی حل نمی‌شود. شاید قیمت‌گذاری چندگروهی می‌خواهی، فرایند سفارش خاص داری یا اتصال انبار و حسابداری برایت محدود است. اگر مسئله با تنظیمات، محتوای بهتر یا یک قابلیت رسمی همان پلتفرم حل می‌شود، مهاجرت کامل ممکن است خرج و کار اضافه ایجاد کند. تغییر فناوری به‌تنهایی فروش بیشتر نمی‌سازد.

برای تصمیم، سه مورد را کنار هم بگذار: محدودیت فعلی، راه‌حل در سایت جدید و مسئول نگهداری آن. مثلاً «انتخاب چند انبار برای هر سفارش» یک نیاز قابل بررسی است؛ «سایت حرفه‌ای‌تر شود» هنوز محدوده روشنی نیست. گزینه ماندن، توسعه روی پلتفرم فعلی و مهاجرت را با همین نیازها مقایسه کن. سایت اختصاصی هم به بودجه نگهداری و تیم پاسخ‌گو نیاز دارد.

پیش از قرارداد، یک نمونه خروجی واقعی بگیر

از پشتیبان سایت‌ساز درباره خروجی مجاز هر بخش بپرس: محصولات و مدل‌ها، تصاویر، دسته‌ها، اطلاعات مشتری، سفارش و وضعیت ارسال. نام فایل یا وجود دکمه خروجی کافی نیست؛ چند ردیف را باز کن و ببین کد کالا، مبلغ، نشانی صفحه و ارتباط سفارش با مشتری داخل آن هست یا نه. نمونه‌ای که برای برآورد می‌فرستی باید اطلاعات شخصی مشتری را نداشته باشد.

خروجی محصول را با پشتیبان کامل فروشگاه یکی نگیر. برای نمونه، راهنمای رسمی Shopify برای سفارش و مشتری، مسیرهای خروجی جدا دارد. پس نباید فرض کنیم یک فایل، تمام داده لازم برای راه‌اندازی دوباره فروشگاه را نگه می‌دارد. قالب و محدودیت پلتفرم خودت را از مستندات و پشتیبان همان سرویس تأیید کن؛ روش یک سایت‌ساز را به همه تعمیم نده.

برای هر بخش یکی از سه تصمیم را ثبت کن

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

این فهرست جلوی اختلاف پس از تحویل را می‌گیرد. اگر در پیشنهاد نوشته شده «انتقال محصولات»، روشن کن آیا مدل‌های رنگ و اندازه، تصاویر هر مدل، دسته‌ها، ویژگی‌ها و محصولات ناموجود هم شاملش هستند. بخش غیرقابل انتقال را از ابتدا مشخص کن؛ حذف بی‌خبرانه داده، جایگزین توافق درباره محدوده نیست.

محصول، مدل و موجودی باید رابطه خود را حفظ کنند

محصول چندمدلی را فقط با نام منتقل نکن. کد هر رنگ و اندازه، قیمت، موجودی و ارتباط آن با محصول اصلی باید در مقصد روشن باشد. واحد فروش را هم تطبیق بده؛ یک بسته با یک عدد کالا متفاوت است. اگر عکس‌ها با نشانی خارجی در فایل آمده‌اند، امکان دریافت مجاز و باقی‌ماندن دسترسی به آن‌ها را قبل از بستن سرویس قبلی بررسی کن.

آزمایش را با نمونه‌های دشوار انجام بده: یک محصول ساده، یک محصول چندمدلی، کالای تخفیف‌دار و محصول ناموجود. تعداد ردیف برابر، به معنی انتقال درست نیست. در سایت جدید همان مدل را انتخاب کن، تصویر و مبلغش را ببین و بعد وضعیت آن را در پنل بررسی کن. پاک‌سازی کدهای تکراری و دسته‌های نامرتب می‌تواند بخش جداگانه‌ای از کار باشد.

سابقه سفارش را به پرداخت تازه تبدیل نکن

سفارش قدیمی یک سابقه است. هنگام واردکردن آن، نباید دوباره پرداخت انجام شود، پیام خرید تازه ارسال شود یا موجودی دوباره کم شود. پیش از انتقال، روشن کن شماره سفارش قبلی چطور قابل جست‌وجو می‌ماند و مبلغ، واحد پول، تخفیف، ارسال و وضعیت آن چطور در مقصد نمایش داده می‌شوند. برای سفارش باز و مرجوعی در جریان، مسئول پیگیری تعیین کن.

مهاجرت را با یک سناریوی نمونه بسنج: سفارشی که پیش از جابه‌جایی ثبت شده، اما بعد از آن ارسال یا مرجوع می‌شود. تیم باید بداند آن را در کدام پنل پیگیری کند و کجا اصلاح بزند. اگر نگهداری سابقه در بایگانی جدا انتخاب شده، دسترسی و مدت نگهداری را مکتوب کن؛ نمایش محدود بایگانی را «انتقال کامل سفارش‌ها» معرفی نکن.

حساب مشتری و رمز ورود چه می‌شود؟

قابل انتقال بودن مشخصات مشتری، به معنی قابل انتقال بودن رمز ورود او نیست. این موضوع به خروجی مجاز پلتفرم و سازگاری روش ورود وابسته است. اگر انتقال معتبر رمز ممکن نیست، مسیر فعال‌سازی یا بازیابی حساب در سایت جدید را طراحی کن. از گرفتن یا فرستادن رمزهای قابل خواندن برای حل این مشکل استفاده نکن.

برای آزمون، یک حساب آزمایشی با چند سفارش در نظر بگیر. پس از انتقال، صاحب همان حساب باید بتواند وارد شود و فقط سوابق مجاز خودش را ببیند. تطبیق مشتری را صرفاً با شباهت نام انجام نده؛ روش شناسایی و رسیدگی به شماره یا ایمیل مشترک باید مشخص باشد. داده‌های هویتی، رضایت‌ها و فایل‌های خصوصی را هم در محیط عمومی آزمایش یا فرم درخواست پروژه قرار نده.

نشانی صفحه‌ها را قبل از طراحی فهرست کن

صفحه محصول، دسته‌بندی، مقاله و صفحات مهم فروشگاه فعلی را فهرست کن. در صورت امکان، نشانی ارزشمند را حفظ کن؛ اگر عوض می‌شود، مقصد واقعاً مرتبط آن را مشخص کن. برای صفحه‌های جابه‌جاشده، راهنمای گوگل استفاده از انتقال مناسب به مقصد جدید را توضیح می‌دهد و از هدایت همه نشانی‌های قدیمی به صفحه اصلی نامرتبط پرهیز می‌دهد.

مثلاً صفحه قدیمی یک مدل کفش باید به همان محصول یا جایگزین واقعاً مرتبط برسد، نه صرفاً ویترین عمومی. تکلیف محصول حذف‌شده هم جداست. پیش از قرارداد بپرس پلتفرم قدیمی چه اختیارهایی برای تغییر مسیر می‌دهد. اگر نشانی قبلی روی زیردامنه متعلق به سرویس است و کنترلی روی آن نداری، محدودیت را پیش از وعده انتقال سئو ثبت کن.

دامنه، ایمیل و اتصال‌ها را در برنامه جابه‌جایی ببین

مالکیت حساب دامنه، دسترسی تنظیمات و مسئول تغییر آن را قبل از روز انتشار روشن کن. تغییر مقصد وب‌سایت نباید بدون بررسی روی ایمیل سازمانی یا سرویس‌های دیگر همان دامنه اثر بگذارد. نسخه جدید باید پیش از تغییر مسیر اصلی، در محیط آزمایشی قابل بررسی باشد و محیط آزمایشی هم از انتشار ناخواسته اطلاعات مشتری محافظت شود.

پرداخت، پیامک، ترب، حسابداری و روش ارسال را به‌عنوان اتصال‌های جدا فهرست کن. انتقال محصولات، فعال‌بودن خودکار این سرویس‌ها در مقصد را تضمین نمی‌کند. برای هرکدام، دسترسی لازم، شرایط ارائه‌دهنده و آزمون مشخص داشته باش. اگر حسابداری مرجع موجودی است، قاعده همگام‌سازی باید با ورود داده اولیه هماهنگ شود تا موجودی تازه دوباره با خروجی قدیمی جایگزین نشود.

در روز انتقال، سفارش‌های بین دو نسخه را گم نکن

بین اولین خروجی آزمایشی و تغییر نهایی، احتمالاً سفارش و تغییر موجودی تازه داری. زمان خروجی آخر، مسئول دریافت تغییرات بعدی و روش تطبیق سفارش‌های این فاصله را تعیین کن. اگر توقف کوتاه سفارش لازم است، مدت و پیام آن باید با کسب‌وکار هماهنگ باشد. قول «بدون حتی یک دقیقه توقف» بدون طراحی و آزمون مسیر فروش قابل اتکا نیست.

یک نقطه تصمیم برای برگشت هم مشخص کن: چه خطایی مانع ادامه است، چه کسی تصمیم می‌گیرد و داده ثبت‌شده پس از شروع نسخه جدید چه می‌شود؟ بازگرداندن ساده یک پشتیبان قدیمی می‌تواند سفارش تازه را از بین ببرد. برنامه برگشت باید حفظ این سفارش‌ها و جلوگیری از پرداخت یا پیام تکراری را هم پوشش دهد.

هزینه مهاجرت را از هزینه ساخت سایت جدا کن

برآورد را در چند ردیف بخواه: ساخت فروشگاه جدید، دریافت و پاک‌سازی داده، تبدیل و ورود اطلاعات، انتقال تصاویر، نگاشت نشانی‌ها، راه‌اندازی اتصال‌ها، آزمون و آموزش، و پشتیبانی بعد از جابه‌جایی. هزینه سرویس قبلی در دوره هم‌پوشانی و هزینه زیرساخت جدید را هم جدا ببین. ممکن است بعضی کارها یک‌باره و بعضی دوره‌ای باشند.

تعداد محصول فقط یکی از عوامل است. تنوع مدل‌ها، کیفیت خروجی، تعداد سفارش‌های باز، فایل‌های خصوصی، محدودیت دسترسی و قواعد اختصاصی روی کار اثر دارند. دو پیشنهاد را با یک فهرست انتقال مشترک مقایسه کن. اگر یکی فقط محصولات را می‌آورد و دیگری سابقه سفارش و نشانی‌ها را هم پوشش می‌دهد، مقایسه مبلغ نهایی آن‌ها به‌تنهایی معنی‌دار نیست.

قبل و بعد از انتشار چه چیزهایی را تحویل بگیری؟

پیش از انتشار، نمونه محصول و مشتری، تطبیق مبلغ و وضعیت سفارش، محدودبودن دسترسی به سوابق و یک خرید آزمایشی را بررسی کن. لینک قدیمی منتخب باید به مقصد درست برسد و صفحات تازه عنوان و توضیح متناسب داشته باشند. نتیجه را با فهرست انتقال مقایسه کن و موارد باقی‌مانده را با مسئول و زمان پیگیری ثبت کن.

پس از انتشار، خطاهای خرید، سفارش‌های جاافتاده و لینک‌های مهم را پایش کن. برای جست‌وجو هم sitemap و صفحات شاخص را در ابزارهای مجاز بررسی کن. گوگل درباره نوسان موقت در فرایند پردازش انتقال توضیح می‌دهد؛ حفظ رتبه یا ایندکس‌شدن در روز مشخص تضمینی نیست. به‌جای این وعده، از مجری گزارش کنترل نشانی‌ها و برنامه رسیدگی به خطا بخواه.

برای سفارش بررسی مهاجرت چه اطلاعاتی بفرستی؟

نام سایت‌ساز فعلی، نشانی فروشگاه، دلیل مهاجرت، تعداد تقریبی محصول و مدل، حجم سفارش و فهرست اتصال‌ها را بنویس. یک خروجی نمونه بدون اطلاعات شخصی و چند نشانی مهم کمک می‌کند محدوده بررسی شود. مشخص کن چه سوابقی باید داخل پنل مشتری بماند و کدام بخش می‌تواند بایگانی باشد. رمز ورود، کلید سرویس و فایل مشتری را داخل فرم عمومی قرار نده.

در گره، امکان انتقال پس از بررسی خروجی مجاز، دسترسی و نیازهای مقصد مشخص می‌شود. لازم نیست از ابتدا همه امکانات را دوباره بسازی؛ نسخه اول باید فروش، پیگیری سفارش و مدیریت روزانه را کامل پوشش دهد. اگر مشکل اصلی هنوز با اصلاح محدود حل می‌شود، همان گزینه را هم در مقایسه نگه دار. هدف، فروشگاه قابل اداره است، نه صرفاً تغییر نام فناوری.

پرسش‌های مرتبط