Migrate from NetCat to Bitrix: Preserve Traffic and Data

You are running a site on NetCat that has been in operation since 2012? Chances are you’ve already run into issues: slow page loads (2–4 seconds), outdated visuals, and difficulties integrating a modern tech stack. We have completed over 50 successful migrations from NetCat to 1C-Bitrix — and each time we encountered a non‑standard data storage architecture. After migration, page load speeds on Bitrix are 3–5 times higher thanks to tagged caching, and SEO traffic remains at the previous level if 301 redirects are properly configured. Our experience — over 5 years on the market, 50+ completed projects — guarantees data integrity and full documentation after launch.

How to Migrate Data Without Loss?

NetCat’s data structure is fundamentally different from Bitrix’s. NetCat uses the concept of “components” — similar to Bitrix information blocks. Each component has its own database table with a name like netcat_main_<component_id>. That means there is no single “elements” table — each content type lives in its own table, whose schema is defined by the component settings.

Key NetCat system tables:

• netcat_main_catalogue — site section catalog
• netcat_main_component — component types (analogous to infoblock types)
• netcat_main_field — component fields
• netcat_main_sub_class — subclasses (binding components to sections)
• nc_file — file archive

For each component with ID=5 there is a table netcat_main_5 containing its data. Before migration, you need to extract the schema of all such tables and build a mapping to Bitrix information blocks.

Extracting the Structure via SQL

-- Get all components and their fields
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;

-- Get data for a specific component
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 field types (string, text, integer, float, checkbox, file, image, date, select) map to Bitrix infoblock property types: S, S/html, N, N, L, F, F, D, L respectively.

Site Structure and Navigation

Section hierarchy in NetCat is stored in netcat_main_catalogue with the field Parent_Sub_Class. This tree must be recreated in Bitrix — either as infoblock sections (CIBlockSection) or as a site structure via menus. Depending on the content type of each section, you choose the appropriate approach.

Moving Files and Images

NetCat stores files in the /netcat/files/ folder with its own subfolder structure. The nc_file table stores metadata: file name, path, type. During migration, files are transferred using CFile::SaveFile() in Bitrix, creating entries in the b_file table.

Images in NetCat are often stored directly in an HTML content field with absolute paths. After transfer, all such paths need to be updated — via SQL replacement in the database or a script that iterates through infoblock elements.

Forms and Feedback

NetCat has a built‑in form module (netcat_form_* tables). Forms are moved to the Bitrix “Web Forms” module or implemented using the bitrix:form.result.new component. Accumulated submissions are migrated only if critical for business; otherwise they are archived.

What About SEO Positions After Migration?

URLs in NetCat are generated by their own rules and often do not match the URLs that will be in Bitrix. Before the move:

1. Export all old site URLs (via a crawler or from the netcat_main_catalogue table)
2. Build a mapping of old URL → new URL
3. Set up 301 redirects via .htaccess or the bitrix:redirect module
4. Transfer title and description from the Sub_Class_Otsek field and associated SEO fields

Typical Timeframes

The NetCat template and design are not transferred — they are rebuilt from scratch on a Bitrix template. This is standard practice: the outdated site’s visual part usually requires an update along with the platform change.

NetCat vs 1C-Bitrix in Numbers

What Is Included in the Work

• Audit of the old site: inventory of components, fields, files
• Creation of a migration plan with data mapping
• Transfer of all data: items, sections, files, users
• Configuration of 301 redirects and URL mapping
• Testing of migrated functionality and integrations
• Delivery of full documentation for the new project
• One hour of post‑launch support for resolving unexpected situations

Contact us for a free estimation of your project. We guarantee data integrity, set up 301 redirects, and help with initial indexing. Get a consultation — write to us.

Why URL Structure Matters in Bitrix Migration?

Skipping URL mapping during a website migration to Bitrix crashes organic traffic by 50–80% in two weeks. WordPress uses /product/item-name/, OpenCart uses /index.php?route=product/product&product_id=123, Bitrix defaults to /catalog/section/element/. Without a 301 redirect map, search engines index mass 404s. We start every migration with Screaming Frog scanning the old site, then compile a complete redirect map before writing a single line of code. Proper migration requires full URL mapping — every indexed page gets a correspondent.

Over seven years we have completed 50+ projects: landing pages, catalogs with 300,000 products, e‑commerce stores. Typical duration 2–8 weeks. Contact us for a free project estimate within one day.

How Migration Preserves SEO Positions

Losing organic traffic is the biggest fear, and it's justified. Here is how we avoid it.

• URL mapping 1:1 — where possible, via CUrlRewriter and infoblock SEF settings we keep the exact structure. When impossible — 301 redirect. Auto‑generation of redirect map: parse Screaming Frog export, match with new element slugs, generate nginx config. Each redirect verified with curl -I after switching.
• Transfer of meta tags — title, description, h1 moved into properties ELEMENT_META_TITLE and ELEMENT_META_DESCRIPTION. Canonical via Bitrix SEO component. Duplicates cut: www/non‑www, http/https, sorting parameters. Sitemap: new sitemap.xml generated by Bitrix seo module, submitted to Search Console immediately after DNS switch.
• Speed comparison — Bitrix processes a catalog of 100,000 products 3x faster than OpenCart due to tagged caching and query optimization for b_catalog_product.

What Data Gets Transferred?

Content — pages, articles, news → information infoblocks. Catalog: categories → sections, products → elements linked to b_catalog_product, properties → infoblock properties or highload directories. Images, reviews, FAQ.

E‑commerce — products with trade offers (SKUs), prices in b_catalog_price (multi‑currency via b_catalog_currency), stock balances b_catalog_store_product, discounts (b_sale_discount), order history (b_sale_order + b_sale_basket).

Users — client base b_user plus custom UF fields. Passwords are hashed differently: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. We write a custom CUser::LoginByHash with fallback to old algorithm — client enters password once, system rehashes to Bitrix bcrypt.

SEO data — meta tags, alt attributes, URL structure. Main task: preserve every indexed URL or set 301.

Media — images, documents, videos — transferred preserving paths and optimized via CFile::MakeFileArray().

How to Plan a Successful Migration: 5 Key Steps

1. Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
2. Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
3. Migration scripts — PHP scripts read from old DB (or API), transform and write via Bitrix API (CIBlockElement::Add, \Bitrix\Sale\Order::create). Re‑run during testing.
4. Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
5. Final migration & switching — delta import, DNS switch, monitoring.

Typical Migration Mistakes and How to Avoid Them

Each of these errors has caused loss of positions and clients.

• Loss of URLs without redirects — the most destructive mistake. /product/123 instead of /catalog/item-name.html — without 301 this means mass 404s and traffic collapse. We auto‑generate the map and verify every redirect after switching.
• Content duplication — one product accessible with and without www, via HTTP and HTTPS, with GET filter parameters → five URLs instead of one. SEO weight dilutes. Set up canonical, 301 for variants, robots.txt with Disallow for parameters.
• Broken images — absolute URLs in content (src="https://old-site.ru/img/photo.jpg"), quality loss during compression. Replace with relative paths, transfer preserving structure, check HTTP 200 for each file.
• Loss of meta tags and microdata — title, description, Schema.org may not transfer. Do full mapping and verify on staging.
• Broken forms and integrations — changed IDs, API keys, webhooks. Compile integration register before start and test each after.
• Mobile version — old m.site.ru → responsive Bitrix. Without mobile URL redirect → 404 for mobile users. Include in redirect map.

Timelines and Cost Savings

Businesses typically save $3,000–$8,000 annually after migration — no old CMS license fees, reduced plugin and hosting costs. Annual hosting savings alone can reach $1,200. Add the affordable licensing cost of 1C‑Bitrix — it pays off quickly.

Contact us for a free migration estimate. We also provide a preliminary calculation within one day — request a consultation with our Bitrix specialists.