Переписать или перенести: что из старого сайта стоит сохранить

Часть 5 из 7 · Серия «Старый сайт — новая рабочая система»

«А можно просто перенести всё как есть, только на новую платформу?»

Вопрос звучит на каждом втором обсуждении, и за ним стоит разумное желание: не платить дважды за то, что уже работает. Проблема в том, что «всё» — это не одна сущность. Старый сайт состоит из слоёв, и решение по каждому слою разное.

Разберём, что переносится почти всегда, что почти никогда и что по ситуации.

Четыре слоя старого сайта

Данные — товары, категории, клиенты, заказы, тексты страниц, отзывы. То, что накопилось за годы работы.

Медиа — фотографии, документы, каталоги в PDF. Технически тоже данные, но живут отдельно и переносятся отдельно.

Оформление — шаблоны, вёрстка, стили. Как сайт выглядит.

Логика — как считается доставка, как работают скидки, что происходит при оформлении заказа, какие цены видит оптовик. Как сайт себя ведёт.

Дальше по каждому слою.

Данные: сохраняем почти всегда

Простой критерий: данные нельзя воссоздать. Если потерять базу клиентов или историю заказов, восстановить их неоткуда. Поэтому переносят практически всегда.

Но «переносим» не равно «переносим всё подряд». В чек-листе из третьей части был пункт про объём данных — вот здесь он и пригождается. Товары, снятые с продажи пять лет назад, заказы за период, который уже не нужен бухгалтерии, клиенты, не заходившие ни разу с регистрации, — всё это можно оставить архивом в старой базе.

Переезд — редкая возможность выкинуть накопившийся мусор. Второй такой не будет ещё лет пять.

Оформление: почти никогда

Здесь ожидания расходятся с реальностью сильнее всего.

Шаблоны старого сайта написаны под старую систему: её разметку, её способ выводить данные, её ограничения. На новую платформу они не переносятся — переносится только внешний вид, и то через повторную вёрстку по образцу.

То есть «сохранить дизайн» на практике означает «сверстать заново, глядя на старый сайт». Работы столько же, сколько на новое оформление, но с наследованием всех ограничений прежнего.

Исключение одно: если редизайн делали недавно и он вас устраивает. Тогда сохраняют не файлы, а визуальную концепцию — палитру, шрифты, логику расположения блоков. Это разумно и экономит время на согласованиях.

Во всех остальных случаях стоит вспомнить, что устаревший вид обычно и был одной из причин переделки. Как отличить, когда нужен редизайн, а когда переделка, разбирали во второй части.

Логика: по ситуации

Самый интересный слой, и здесь важно понять одну вещь:

Переносится не код, а правила.

Код старой системы на новую платформу не переезжает в принципе — языки, версии и устройство разные. Переезжает описание того, как должно работать. И вот его ценность бывает огромной.

Логика достойна сохранения, если она отражает реальный бизнес-процесс, который сложился годами и работает: как считается цена для оптовика в зависимости от объёма, какие условия доставки для разных регионов, что происходит с заказом при частичном наличии. Это знание о вашем бизнесе, оформленное в правила, и придумать его заново дорого.

Логику стоит пересмотреть, если ответ на вопрос «почему так?» звучит как «так исторически сложилось» или «это ещё Сергей делал, он давно уволился». Такие правила переносят по инерции, а потом годами обходят.

Практический приём: попросите исполнителя выписать все нестандартные правила старого сайта отдельным списком. По каждому пункту ответьте, нужен он или нет. Обычно треть отпадает сразу.

Три типовых сценария

Большой каталог, простая логика. Магазин на устаревшей CMS: десятки тысяч позиций, но заказ устроен обычно. Здесь переносят данные, а систему пишут заново — и это самый предсказуемый вариант. Основная работа — сопоставление полей и проверка полноты.

Средний каталог, сложная логика. Оптовые цены, индивидуальные условия для клиентов, нестандартный расчёт доставки. Данные переезжают за дни, а вот выяснение правил занимает недели: значительная часть нигде не записана и живёт в голове у менеджеров. Основной бюджет уходит именно сюда, а не на разработку.

Самописная система, автора нет. Самый дорогой случай. Логику приходится восстанавливать не по коду, а по поведению: смотреть, что система делает, и спрашивать сотрудников, правильно ли это. Часть особенностей оказывается ошибками, которые все привыкли обходить.

Почему «перенести как есть» дороже, чем кажется

Это требование звучит экономно, а обходится дорого — по трём причинам.

Воспроизводятся и ошибки. «Как есть» включает костыли, обходные пути и странности, к которым сотрудники притерпелись. За их воспроизведение платят как за функциональность.

Нечем проверять полноту. Если описания нет, эталоном становится сам старый сайт. А он местами работает неправильно — и это выясняется уже после сдачи.

Платят дважды. Сначала за воспроизведение поведения, потом за исправление того, что воспроизвели. Второй счёт обычно больше первого.

Теряется смысл затеи. Если новая система ведёт себя ровно как старая, то и ручной работы у менеджеров останется ровно столько же. А это, как правило, и было причиной переделки.

Разумная формулировка вместо «как есть»: сохранить результат, а не способ. Заказ должен по-прежнему попадать в учётную систему — но не обязательно тем же путём, что и десять лет назад.

Три вопроса, которые решают спор

Когда непонятно, переносить конкретную вещь или нет:

1. Можно ли это воссоздать, если потерять? Нет — переносим обязательно. Данные почти всегда попадают сюда.
2. Это отражает реальный процесс или историческую случайность? Процесс — сохраняем правило. Случайность — обсуждаем.
3. Мы этим пользуемся? Проверяется по статистике. Значительная часть возможностей старого сайта не используется годами, и это видно в аналитике.

Три вопроса закрывают почти все спорные случаи и экономят недели обсуждений.

Частые вопросы

Можно ли перенести сайт на новую платформу автоматически?

Данные — во многом да, для типовых систем есть готовые способы переноса. Оформление и логику — нет: они слишком завязаны на конкретную платформу.

Сохранятся ли адреса страниц?

Не обязательно, и это нормально — важно настроить переадресацию со старых на новые. Об этом первая часть серии.

Что делать, если никто не помнит, почему сайт работает именно так?

Спрашивать не разработчиков, а тех, кто пользуется: менеджеров, продавцов, бухгалтерию. Обычно правило помнит тот, кому оно мешает.

Дешевле ли перенос, чем разработка с нуля?

Не всегда. Перенос данных дешевле их повторного заведения, а вот перенос логики может оказаться дороже, чем написать её заново по нормальному описанию.

Стоит ли сохранять старый сайт после переезда?

Некоторое время — да, в виде копии и базы. Пригодится и для сверки, и для данных, которые решили не переносить.

Что дальше

Решение принято: что переносим, что пишем заново. Дальше начинается сам перенос, и там свои открытия — поля, которым нет аналога, дубли, товары без артикулов и история заказов, которая переезжает не так гладко, как хотелось. Об этом следующая часть.

Разобраться, что из старого сайта стоит сохранить, можно вместе — покажите текущую систему: siteko.net/development.