Ви обслуговуєте сайт на NetCat, який працює довгий час? Скоріше за все, ви вже зіткнулися з проблемами: повільне завантаження сторінок (2–4 секунди), застарілий візуал та складнощі з інтеграцією сучасного стеку. Ми виконали вже 50+ успішних переносів з NetCat на 1С-Бітрікс — і кожного разу стикалися з нестандартною архітектурою зберігання даних. Після переїзду швидкість завантаження сторінок на Бітрікс у 3–5 разів вища завдяки тегованому кешуванню, а SEO-трафік залишається на попередньому рівні при правильному налаштуванні 301-редиректів. Вартість визначається після аналізу обсягу даних, але економія на підтримці старої системи окупає витрати протягом півроку. Наш досвід — багаторічна робота на ринку, 50+ завершених проектів — дозволяє гарантувати збереження даних та повну документацію після запуску.
Як мігрувати дані без втрат?
Структура даних NetCat принципово відрізняється від Бітрікс. NetCat використовує концепцію «компонентів» — аналогів інфоблоків Бітрікс. Кожен компонент має власну таблицю в базі даних з іменем виду netcat_main_<component_id>. Це означає, що немає єдиної таблиці «елементи» — кожен тип контенту живе у своїй таблиці, схема якої визначається налаштуваннями компонента.
Ключові системні таблиці NetCat:
-
netcat_main_catalogue — каталог розділів сайту
-
netcat_main_component — типи компонентів (аналог типів інфоблоків)
-
netcat_main_field — поля компонентів
-
netcat_main_sub_class — підкласи (прив'язка компонентів до розділів)
-
nc_file — файловий архів
Для кожного компонента з ID=5 існує таблиця netcat_main_5 з даними. Перед міграцією потрібно отримати схему всіх таких таблиць і скласти мапінг на інфоблоки Бітрікс.
Отримання структури через SQL
-- Отримати всі компоненти та їх поля
SELECT c.Component_ID, c.Component_Name, f.Field_Name, f.Type
FROM netcat_main_component c
JOIN netcat_main_field f ON f.Component_ID = c.Component_ID
ORDER BY c.Component_ID, f.Priority;
-- Отримати дані конкретного компонента
SELECT * FROM netcat_main_5
WHERE Catalogue_ID IN (
SELECT Catalogue_ID FROM netcat_main_catalogue WHERE Sub_Class_ID = 12
) AND Hidden = 0;
Тип полів в NetCat (Type: string, text, integer, float, checkbox, file, image, date, select) мапиться на типи властивостей інфоблоку Бітрікс: S, S/html, N, N, L, F, F, D, L відповідно.
Розділи сайту та навігація
Ієрархія розділів в NetCat зберігається в netcat_main_catalogue з полем Parent_Sub_Class. Це дерево потрібно відтворити в Бітрікс: або як розділи інфоблоку (CIBlockSection), або як структуру сайту через меню. Залежно від типу контенту кожного розділу — обирається потрібний підхід.
Перенесення файлів та зображень
NetCat зберігає файли в папці /netcat/files/ з власною структурою підпапок. Таблиця nc_file зберігає метадані: ім'я файлу, шлях, тип. При міграції файли переносяться через CFile::SaveFile() в Бітрікс зі створенням записів в таблиці b_file.
Зображення в NetCat нерідко зберігаються прямо в HTML-полі контенту з абсолютними шляхами. Після перенесення всі такі шляхи потрібно оновити — через SQL-заміну в базі або скрипт обходу елементів інфоблоку.
Особливості форм та зворотного зв'язку
NetCat має вбудований модуль форм (netcat_form_* таблиці). Форми переносяться в модуль «Веб-форми» Бітрікс або реалізуються через компонент bitrix:form.result.new. Накопичені заявки мігрують, тільки якщо це критично для бізнесу — частіше їх просто архівують.
Що робити з SEO-позиціями після переїзду?
URL в NetCat формуються за своїми правилами і нерідко не збігаються з URL, які будуть в Бітрікс. Перед переїздом потрібно:
- Вивантажити всі URL зі старого сайту (через краулер або з таблиці
netcat_main_catalogue)
- Скласти карту відповідностей старий URL → новий URL
- Налаштувати 301-редиректи через
.htaccess або модуль bitrix:redirect
- Перенести title та description з полів
Sub_Class_Otsek та пов'язаних SEO-полів
Типові терміни
| Сайт |
Обсяг |
Термін |
| Корпоративний сайт (5–10 компонентів) |
до 2000 елементів |
3–5 тижнів |
| Каталог продукції |
до 10 000 елементів |
5–8 тижнів |
| Портал з користувачами та формами |
будь-який |
8–12 тижнів |
Шаблон і дизайн на NetCat не переносяться — вони реалізуються заново на шаблоні Бітрікс. Це стандартна практика: візуальна частина застарілого сайту, як правило, потребує оновлення разом зі зміною платформи.
Порівняння NetCat та 1С-Бітрікс в цифрах
| Параметр |
NetCat |
1С-Бітрікс |
| Швидкість завантаження сторінки |
2–4 с (без кешу) |
0.5–1.5 с (з кешем) |
| Гнучкість структури даних |
Обмежена компонентами |
Інфоблоки + HL-блоки |
| Інтеграція з 1С |
Потребує доопрацювань |
З коробки через CommerceML |
| SEO-модуль |
Базовий |
Комплексний (ЧПУ, мета-теги, карти сайту) |
Що входить в роботу
- Аудит старого сайту: інвентаризація компонентів, полів, файлів
- Складання плану міграції з мапінгом даних
- Перенесення всіх даних: елементи, розділи, файли, користувачі
- Налаштування 301-редиректів та карти відповідності URL
- Тестування перенесеного функціоналу та інтеграцій
- Передача повної документації по новому проекту
- Годинна підтримка після запуску для вирішення нештатних ситуацій
Типові помилки при міграції
- Пропуск прихованих елементів (Hidden = 0) — втрачаються дані.
- Неправильний мапінг полів select — в Бітрікс потрібно створювати списки.
- Ігнорування кодування — NetCat часто використовує cp1251, Бітрікс — UTF-8.
- Відсутність редиректів — різке падіння трафіку на 40-60%.
Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Ми гарантуємо збереження даних, налаштовуємо 301-редиректи та допомагаємо з первинною індексацією. Отримайте консультацію — напишіть нам.
Міграція сайтів на 1С-Бітрікс
Переїзд на нову CMS — завжди стрес для сайту. Якщо проігнорувати URL-структуру, через два тижні трафік падає на 50–80 %. WordPress генерує /product/item-name/, OpenCart — /index.php?route=product/product&product_id=123, а Бітрікс за замовчуванням хоче /catalog/section/element/. Без карти 301-редиректів пошуковики фіксують масові 404. Ми починаємо будь-яку міграцію зі сканування старого сайту через Screaming Frog і складаємо повну карту редиректів ще до першого рядка коду. Як сказано в документації 1С-Бітрікс: коректна міграція вимагає повного маппінгу URL.
За 7 років ми перенесли понад 50 проєктів — від лендінгів до каталогів на 300 000 товарів. Середній термін — 2–8 тижнів. Оцінку проєкту робимо безкоштовно за 1 день — зв'яжіться для попереднього розрахунку.
Які CMS ми переносимо на Бітрікс?
За роки роботи дані мігрували з десятків систем.
Блоги та корпоративні сайти: WordPress / WooCommerce → 1С-Бітрікс. Таблиці wp_posts, wp_postmeta, wp_wc_product_meta_lookup маппяться в інфоблоки та highload-блоки. Варіації товарів (WooCommerce Variable Product) стають торговими пропозиціями (b_catalog_product).
Інтернет-магазини: OpenCart / ocStore → 1С-Бітрікс. Структура oc_product, oc_product_description, oc_product_to_category переїжджає в ієрархію інфоблоків. Мультимовність OpenCart перетворюється на мовні версії властивостей. Joomla / VirtueMart, MODX Revolution (TV-змінні → властивості інфоблоків), Drupal, PrestaShop — аналогічно.
SaaS-платформи: Tilda, InSales, Shopify, Wix, Squarespace. Бізнес переріс конструктор — потрібні 1С-інтеграції та управління залишками.
Самописні двигуни: реверсимо БД і відновлюємо бізнес-логіку за вихідним кодом.
Що переноситься?
Контент: сторінки, статті, новини → інформаційні інфоблоки. Каталог: категорії → розділи, товари → елементи з прив'язкою до b_catalog_product, властивості → властивості інфоблоку або highload-довідники. Зображення, відгуки, FAQ.
E-commerce: товари з варіаціями (торгові пропозиції), ціни в b_catalog_price (мультивалютні через b_catalog_currency), залишки по складах b_catalog_store_product, знижки (b_sale_discount), історія замовлень (b_sale_order + b_sale_basket).
Користувачі: клієнтська база — b_user + UF-поля. Паролі в кожній CMS хешуються по-своєму: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. Ми пишемо кастомний CUser::LoginByHash з fallback на старий алгоритм — клієнт вводить пароль один раз, система перехешує в bcrypt Бітрікса.
SEO-дані: мета-теги, alt-теги, URL-структура. Головне завдання — зберегти всі URL або проставити 301-редиректи.
Медіа: зображення, документи, відео — зі збереженням шляхів та оптимізацією через CFile::MakeFileArray().
Як відбувається міграція?
| Етап |
Тривалість |
Що робимо |
| Аудит |
1–3 дні |
Скануємо Screaming Frog: всі URL, статус-коди, мета-теги. Аналізуємо структуру БД, кастомні доробки, інтеграції. Складаємо карту перенесення. |
| Проектування архітектури |
2–5 днів |
Маппінг: типи контенту → інфоблоки, поля → властивості, довідники → highload-блоки. Архітектура має бути зручною для адміністрування в Бітрікс. |
| Скрипти міграції |
3–10 днів |
PHP-скрипти читають зі старої БД (або API), трансформують і пишуть через API Бітрікса (CIBlockElement::Add, \Bitrix\Sale\Order::create). Запускаємо повторно при тестуванні. |
| Staging |
1–2 дні |
Повне перенесення на тестовий сервер. Перевіряємо цілісність: кількість товарів, властивості, URL, фільтри. |
| Дизайн / шаблони |
1–4 тижні |
Редизайн або адаптація верстки під шаблонізатор Бітрікса (template.php, result_modifier.php). |
| 301-редиректи |
1–2 дні |
Повна карта в .htaccess або nginx.conf. Кожен проіндексований URL → відповідна сторінка нового сайту. |
| Фінальна міграція |
1 день |
Дельта-імпорт свіжих даних, перемикання DNS, моніторинг. |
| Постміграційний контроль |
2–4 тижні |
Моніторимо Google Search Console та Яндекс.Вебмастер: індексація, позиції, crawl errors. |
Як зберегти SEO-позиції?
Втрата органічного трафіку — головний страх, і він обґрунтований. Ось як ми його уникаємо.
Маппінг URL 1:1 — де можливо, через CUrlRewriter та ЧПУ-налаштування інфоблоку зберігаємо точну структуру. Де не можна — 301. Автогенерація карти редиректів: парсимо експорт Screaming Frog, зіставляємо з slugs нових елементів, генеруємо конфіг nginx. Кожен редирект перевіряється curl -I після перемикання.
Перенесення мета-тегів: title, description, h1 переносяться як є у властивості ELEMENT_META_TITLE, ELEMENT_META_DESCRIPTION. Canonical: rel="canonical" через SEO-компонент Бітрікс. Дуби відсікаємо: www/без www, http/https, параметри сортування. Sitemap: нова sitemap.xml через модуль seo Бітрікса, подача в Search Console та Вебмастер одразу після перемикання.
Порівняння швидкості: Бітрікс у 3 рази швидше обробляє каталог із 100 000 товарів, ніж OpenCart, завдяки тегованому кешуванню та оптимізації запитів до b_catalog_product.
Що входить у роботу (deliverables)
| Що отримує клієнт |
Опис |
| Документація |
Карта редиректів, опис маппінгу, схема БД |
| Доступи |
Адміністративна панель, FTP/SSH, API-ключі |
| Навчання |
Відеоуроки або консультація з роботи з Бітрікс |
| Підтримка |
2 тижні постміграційного моніторингу та фіксу багів |
| Гарантія |
Повернення до старого сайту протягом 48 годин при форс-мажорі |
Міграція інтеграцій
Зовнішні інтеграції — окремий пласт. Ми перепідключаємо:
- Платіжні системи —
sale.paysystem зі збереженням історії транзакцій.
- Доставка — налаштування
sale.delivery.handler (СДЕК, Укрпошта).
- CRM — прив'язка до Бітрікс24 або збереження поточної через REST API.
- 1С — налаштування обміну через CommerceML. Часто це головна причина міграції на Бітрікс.
- Email-маркетинг — перенесення підписників, шаблонів, вебхуків.
- Аналітика — e-commerce tracking під нову структуру dataLayer.
Типові помилки при міграції
Кожна з цих помилок призводила до втрати позицій і клієнтів.
Втрата URL без редиректів — найруйнівніший промах. /product/123 замість /catalog/item-name.html — без 301 це масові 404 та обвал трафіку. Ми генеруємо карту автоматично і перевіряємо кожен редирект після перемикання.
Дублювання контенту: один товар доступний з www і без, по HTTP і HTTPS, з GET-параметрами фільтрації — п'ять URL замість одного. SEO-вага розмивається. Налаштовуємо canonical, 301 для варіацій, robots.txt з Disallow для параметрів.
Биті зображення: абсолютні URL в контенті (src="https://old-site.ru/img/photo.jpg"), втрата якості при перетисканні. Замінюємо на відносні шляхи, переносимо зі збереженням структури, перевіряємо HTTP 200 для кожного файлу.
Втрата мета-тегів і мікророзмітки: title, description, Schema.org можуть не перенестися або перенестися криво. Робимо повний маппінг і перевірку на staging.
Відвалені форми та інтеграції: змінилися ID, API-ключі, вебхуки. Складаємо реєстр усіх інтеграцій до початку і перевіряємо кожну після.
Мобільна версія: старий m.site.ru → адаптивний Бітрікс. Без редиректу мобільних URL — 404 для мобільних користувачів. Враховуємо в карті редиректів.
Перед міграцією обов'язково: 1) повне сканування Screaming Frog / Sitebulb; 2) експорт SEO (title, description, h1, canonical, hreflang); 3) фіксація позицій за ключовими запитами; 4) бекап файлів і БД з перевіркою відновлення; 5) реєстр усіх інтеграцій; 6) карта редиректів для кожної проіндексованої сторінки; 7) тестова міграція на staging з повною перевіркою; 8) коректна мобільна версія та редиректи з m.site.ru; 9) нова sitemap.xml готова до подачі; 10) план відкату: DNS збережені, конфіг задокументовано, доступ до старого хостингу є.
Терміни та економія
| Тип проєкту |
Терміни |
Коментар |
| Інформаційний сайт (до 500 стор.) |
2–4 тижні |
Контент + дизайн + редиректи |
| Інтернет-магазин (до 10 000 товарів) |
4–8 тижнів |
Каталог + замовлення + інтеграції |
| Великий магазин (100 000+ товарів) |
2–4 місяці |
Кастомні скрипти + навантажувальне тестування |
Економія: після міграції ви перестаєте платити за ліцензію старої CMS та підтримку застарілого коду. Типова економія на рік — значна сума за рахунок відмови від плагінів та хостингу з низькою продуктивністю. Додайте сюди вартість ліцензії 1С-Бітрікс (редакція «Бізнес») — вона повністю окупається в перший місяць.
Отримайте консультацію з міграції: заповніть форму на сайті, і ми підготуємо пропозицію за 1 день. Оцінимо ваш проєкт безкоштовно — напишіть нам для розрахунку.
