Перенос товаров в новый интернет-магазин кажется самой простой частью переезда: выгрузили CSV со старого сайта, загрузили в новый — готово. На практике именно здесь теряются характеристики и варианты товаров, по которым работали фильтры, у клиентов сбрасываются пароли без предупреждения, история заказов отрывается от покупателей, а накопленные бонусы обнуляются. Всё это не видно в день запуска и вылезает через неделю жалобами клиентов. Разбираем восемь типичных ошибок и как спланировать перенос данных так, чтобы в нём не было пробелов.
- Товары, клиенты и заказы переносят скриптами, а не ручной загрузкой CSV, — с сопоставлением полей и проверкой выборки.
- Сначала решают, что главный источник каталога: старый сайт или 1С.
- Данные переносят дважды: основной массив заранее и разницу за последний день в ночь переключения.
- Каждое расхождение между старой и новой логикой — пароли, бонусы, скидки — решают на аудите, а не после запуска.
Ошибка 1. Импорт товаров из CSV «как есть»
Импорт товаров из CSV — штатная функция почти любой CMS. Проблема в том, что у каждой платформы своя модель данных. На старом сайте «Цвет» и «Размер» могли быть отдельными свойствами, а в выгрузке они склеились в одну текстовую колонку. При загрузке «как есть» свойства превращаются в текст в описании, и фильтр каталога по ним не работает.
Правильный порядок: сначала составить таблицу сопоставления — какое поле старой платформы становится каким свойством новой, какие значения нужно нормализовать («красный», «Красный», «красн.» — одно значение), какие поля не нужны вовсе. Только потом писать импорт. При переносе сайта на другую CMS мы переносим товары скриптами миграции: так быстрее и без ошибок ручного копирования, а сопоставление полей проверяем на выборке до полной загрузки.
Ошибка 2. Потерянные варианты товаров
Футболка в пяти размерах и трёх цветах — это один товар с пятнадцатью вариантами или пятнадцать отдельных товаров? На разных платформах по-разному. При неаккуратном переносе варианты либо разваливаются на отдельные карточки, которые дублируют друг друга в каталоге и поиске, либо теряются, и остаётся только первый вариант.
Отдельно проверяйте, у чего свои цены, остатки, артикулы и фото — у товара или у варианта. Если на старом сайте у каждого размера был свой остаток, а на новом остаток привязан к товару целиком, магазин начнёт продавать то, чего нет на складе.
Проверять перенос по нескольким «красивым» товарам из главной категории. Ошибки сопоставления всплывают на сложных позициях: с вариантами, комплектами, нестандартными единицами измерения, товарах без фото. Выборку для проверки составляйте из самых неудобных карточек.
Ошибка 3. Два источника правды: старый сайт и 1С
Если магазин работает с 1С, главный вопрос — откуда брать каталог на новом сайте. Если перенести товары со старого сайта, а потом включить обмен с 1С, обмен начнёт создавать дубли: у товаров на сайте и в 1С разные идентификаторы. В итоге в каталоге по две карточки одного товара, а остатки обновляются только у одной.
Решение зависит от того, где данные полнее. Обычно номенклатуру, цены и остатки берут из 1С, а описания, фото, SEO-тексты и мета-теги — со старого сайта, и связывают их по артикулу. Это нужно решить на этапе плана, а не в ночь запуска. Подробно о том, как устроен обмен и почему он «не работает» у многих магазинов, — в статье об обмене сайта с 1С.
Ошибка 4. Фото, которые остались на старом сервере
В выгрузке товаров фото часто указаны ссылками на старый сайт. Импорт проходит, картинки отображаются — потому что старый сервер ещё работает. Через месяц хостинг старого сайта отключают, и каталог остаётся без фото. Вторая проблема — alt-тексты и порядок фото в галерее, которые при простом импорте теряются.
Изображения и файлы должны физически переехать на новый сервер вместе с подписями и alt. Заодно их стоит оптимизировать по весу — после переезда магазин обычно загружается быстрее старого.
Ошибка 5. Перенос базы клиентов интернет-магазина без плана по паролям
Клиенты — это не только имена и телефоны, но и учётные записи с паролями. Пароли хранятся в виде хэшей, и разные платформы используют разные алгоритмы. Иногда хэши можно перенести и научить новую платформу их проверять, иногда это невозможно — например, облачные платформы пароли не отдают.
Ошибка — молча сбросить всем пароли. Покупатель приходит за повторным заказом, не может войти и уходит. Правильно: заранее решить, переносим пароли или просим задать новые, и во втором случае подготовить письмо или сообщение с понятной ссылкой. Мы решаем это на аудите — зависит от платформ.
Ещё одна частая проблема — дубли клиентов. На старом сайте один человек мог зарегистрироваться дважды, телефоны записаны в разных форматах: «8 701…», «+7701…», «701…». Перед переносом телефоны приводят к одному формату, а дубли склеивают, иначе в CRM и рассылках будет хаос.
Ошибка 6. Перенос заказов на новую платформу без связей и статусов
Историю заказов переносят, чтобы покупатель видел свои прошлые покупки в личном кабинете, а вы — статистику продаж. Типичные провалы: заказы перенесли, но не связали с клиентами; статусы превратились в «новый» у всех заказов; номера старых заказов пересеклись с новой нумерацией, и менеджеры путают заказы.
Статусы старой и новой платформы нужно сопоставить так же, как свойства товаров, а для новой нумерации — выбрать стартовый номер выше последнего старого.
Ошибки 7–8. Бонусы и синхронизация в ночь запуска
Обнулённые бонусы и сломанные скидки
Самая болезненная для клиентов ошибка. Покупатель копил баллы, а после переезда видит ноль. Логика скидок, промокодов и бонусов на разных платформах разная: где-то баллы начисляются за заказ, где-то за оплату, где-то у них есть срок жизни. Переносим правила, которые поддерживает новая платформа, остальное пересобираем её штатными средствами, а разницу показываем на аудите, чтобы вы заранее решили, что оставить. Балансы бонусов клиентов переносятся отдельно и проверяются выборочно до запуска.
Один перенос за месяц до запуска
Данные перенесли в начале проекта, тестировали месяц, а в день запуска оказалось, что за это время пришли сотни заказов, новые клиенты и изменились остатки. Перенос должен быть двухэтапным: основной массив — заранее, а в ночь переключения — синхронизация того, что появилось за день. Тогда старый магазин работает до последней секунды, а новый стартует с актуальными данными.
ПРАВИЛОПеренос данных — это не загрузка файла, а маленький проект: сопоставление, скрипт, выборочная проверка, повторная синхронизация.
Как спланировать перенос данных без пробелов
| Данные | Что решить заранее | Как проверить |
|---|---|---|
| Товары и свойства | Таблица сопоставления полей, нормализация значений | Фильтры каталога работают на всех свойствах |
| Варианты | У чего цены, остатки, фото: товар или вариант | Выборка из сложных товаров |
| Источник каталога | 1С или старый сайт, ключ связи — артикул | Нет дублей после первого обмена |
| Клиенты | Пароли: перенос или новый, формат телефонов, дубли | Тестовый вход старым клиентом |
| Заказы | Сопоставление статусов, связь с клиентами, нумерация | Личный кабинет показывает историю |
| Бонусы и скидки | Какие правила оставить, как перенести балансы | Баланс выборочных клиентов совпадает |
Всё это входит в пакет «Перенос магазина» у нас — от 1 400 000 ₸ и 4–6 недель: товары с характеристиками, ценами, остатками и фото, клиенты, заказы и статусы, настройка обмена с 1С, Kaspi, оплаты и доставки, проверка на тестовом домене и переключение за одну ночь. Точную смету считаем после бесплатного аудита.
- Составлена таблица сопоставления полей и свойств товаров
- Решено, где хранятся цены, остатки и фото: у товара или у варианта
- Определён главный источник каталога и ключ связи с 1С
- Фото физически перенесены на новый сервер с alt-текстами
- Решено, что делать с паролями клиентов, подготовлено сообщение покупателям
- Телефоны приведены к одному формату, дубли клиентов склеены
- Статусы заказов сопоставлены, заказы связаны с клиентами
- Стартовый номер новых заказов выше последнего старого
- Балансы бонусов перенесены и проверены на выборке
- Запланирована синхронизация данных в ночь переключения
- Проверена выборка из самых сложных товаров
Переносить данные или начинать магазин заново
Иногда старые данные в таком состоянии, что переносить их дороже, чем собрать заново: свойства заполнены хаотично, половина товаров снята с продажи, описания скопированы у поставщиков. Тогда разумно совместить переезд с пересборкой каталога и дизайна. Для этого есть редизайн магазина с переносом данных — каталог, 1С, Kaspi, база клиентов и история заказов переезжают, а витрина и структура обновляются. Если же нужен новый магазин с нуля — с аналитикой воронки, UX каталога и чекаута, — это разработка интернет-магазина под ключ, куда из старого сайта переносятся только клиенты, заказы и то, что действительно ценно.
Проведём бесплатный аудит данных вашего магазина и покажем, что переносится автоматически, а что потребует решений до старта.
Обсудить перенос магазинаМожно ли просто импортировать товары из CSV?
Можно, если каталог простой и свойства на старой и новой платформе совпадают. В остальных случаях нужна таблица сопоставления полей и скрипт миграции, иначе потеряются свойства и варианты.
Сохранятся ли пароли клиентов при переносе базы?
Зависит от платформ: иногда хэши паролей можно перенести, иногда нет. Во втором случае клиентам заранее готовят сообщение с предложением задать новый пароль.
Зачем переносить старые заказы на новую платформу?
Чтобы покупатели видели историю покупок в личном кабинете и могли повторить заказ, а вы сохранили статистику продаж и данные для программ лояльности.
Справитесь с каталогом на 20 000 товаров?
Да, товары переносятся скриптами, поэтому объём — вопрос времени проверки, а не возможности.
