Database Migration between PostgreSQL, MySQL, MongoDB

When a DBMS change is needed: real scenarios

We've encountered projects where a company decides to migrate from MySQL to PostgreSQL due to lack of window functions, or from MongoDB to a relational DBMS for ACID transactions. Another common case is migrating from MySQL to PostgreSQL to work with geodata via PostGIS. Changing a database type is not just a table dump: schema transformation, integrity checks, and performance tuning are required. Our experience includes over 50 migrations in 5 years working with databases from 10 GB to 5 TB. We know the typical pitfalls and how to avoid them.

What are the risks when migrating between different DBMS?

The main difficulties are differences in data types, case sensitivity, NULL handling, and dates. Below is a type mapping table for three popular DBMS:

Another typical issue is zero dates (0000-00-00): PostgreSQL does not accept them, they must be replaced with NULL. Also, queries with non-standard GROUP BY need rewriting, and backticks must be removed.

How we migrate data: stack and tools

We use specialized ETL tools and custom scripts for automation. Consider two popular scenarios.

MySQL → PostgreSQL with pgloader

pgloader is the best choice for direct transfer. It converts 3x faster than a manual approach and automatically handles indexes, foreign keys, and sequences. Example configuration:

LOAD DATABASE
  FROM mysql://user:pass@mysql-host/myapp
  INTO postgresql://user:pass@pg-host/myapp

WITH include no drop,
     create tables,
     create indexes,
     reset sequences

SET work_mem to '256MB',
    maintenance_work_mem to '512MB'

CAST type datetime to timestamptz using midnight-in-utc,
     type tinyint(1) to boolean using tinyint-to-boolean,
     type enum to text,
     column orders.status to text

ALTER SCHEMA 'myapp' RENAME TO 'public'

EXCLUDING TABLE NAMES MATCHING 'cache_*', 'sessions'
;

pgloader allows flexible casting and exclusion of unnecessary tables. Comparison with manual ETL:

MongoDB → PostgreSQL with normalization

MongoDB stores nested documents, which in the relational model require separate tables. Our Python script processes collections in batches, using jsonb for a flexible metadata field:

from pymongo import MongoClient
import psycopg2
from psycopg2.extras import execute_batch
import json

mongo = MongoClient('mongodb://localhost:27017')
pg = psycopg2.connect('host=pg-host dbname=myapp user=app')

source = mongo.myapp.users
cursor = pg.cursor()
batch = []

for doc in source.find():
    batch.append((
        str(doc['_id']),
        doc.get('email'),
        doc.get('name'),
        json.dumps(doc.get('metadata', {})),
        doc.get('created_at')
    ))
    if len(batch) >= 1000:
        execute_batch(cursor,
            """INSERT INTO users (id, email, name, metadata, created_at)
               VALUES (%s, %s, %s, %s::jsonb, %s)
               ON CONFLICT (id) DO NOTHING""",
            batch)
        pg.commit()
        batch = []

if batch:
    execute_batch(cursor, query, batch)
    pg.commit()

For nested arrays (e.g., addresses) we create a separate table with a foreign key and transfer data in a loop.

Why zero-downtime is the standard for business-critical systems?

To avoid downtime, we implement the dual-write pattern. Each write is duplicated to both DBMS, reads remain on the old one until historical data is synced. After switching reads and a week of monitoring, we decommission the old database. Repository code:

class DualWriteRepository:
    def __init__(self, primary, secondary):
        self.primary = primary
        self.secondary = secondary

    def create_user(self, data):
        result = self.primary.create_user(data)
        try:
            self.secondary.create_user(data)
        except Exception as e:
            logger.error(f"Secondary write failed: {e}")
            queue.put(('create_user', data))
        return result

This approach reduces data loss risk to 0.01% and allows rollback at any time. We guarantee 99.99% integrity under normal dual-write operation.

How to guarantee data integrity?

We verify row counts and checksums across all tables. For PostgreSQL we use md5 on sorted data:

SELECT md5(array_agg(md5(id::text || email))::text)
FROM (SELECT id, email FROM users ORDER BY id) t;

MySQL yields a similar hash, and after migration they must match. Additionally, we perform a 10% random sample comparison.

How we test the migration?

Testing is key. We deploy a full copy of the database on a staging environment, run scripts, compare hashes, and perform load testing. Only after successful testing do we start dual-write on production. If something goes wrong, we roll back to the original DB.

Process overview

What's included and guarantees

• Documentation of final schema and type mapping.
• Migration and rollback scripts.
• Test run on a full copy of the database.
• Training the team on the new DBMS.
• 2-week post-deployment support.
• 99.99% data integrity guarantee.

Timeline and cost

For databases up to 100 GB, migration takes from 3 working days (MySQL to PostgreSQL) to 2 weeks (MongoDB to PostgreSQL with normalization). Cost is calculated individually after assessing data volume and transformation complexity. Contact us for a consultation and get an individual migration plan with no obligations. Order a preliminary audit of your database!

Website Redesign and Migration: CMS Change, SEO Preservation

A client came to us 6 weeks after a self-attempted redesign: 'We moved from WordPress to Tilda, traffic dropped by 70%.' I opened Google Search Console — 847 pages returned 404, the URL structure had completely changed, not a single 301 redirect was in place. Yandex hadn't reindexed the new site yet, positions collapsed. Recovery took 4 months and resulted in significant revenue loss for the quarter. Our experience — over 7 years and 80+ successful migrations, we guarantee position retention with the right approach.

Why Do Migrations Break SEO?

Search engines have indexed specific URLs. If /catalog/shoes/nike-air-max-270 turned into /products/nike-air-max-270 without a 301 redirect — all the link equity, traffic, and rankings go nowhere. Google says 301 passes ~99% of PageRank, but in practice positions recover over 2–8 weeks, not instantly.

Commonly, SEO gets broken not out of malice, but because a developer doesn't view the URL structure as a public API. Here are typical breakages:

How to Recover Traffic After a Failed Migration?

If traffic dropped, act immediately:

1. Crawl the new site for 404s and compare with the pre-migration URL list.
2. Create redirects for all lost pages with traffic >0.
3. Check structured data and meta tags on a test sample.
4. Daily monitor Coverage in Search Console and positions for top 50 queries.
5. If after 2 weeks traffic does not recover — deep audit of redirects (transitivity, chains, loops).

In our practice, a large e-commerce site lost 50% of traffic when moving from Bitrix to React + Strapi. We restored 95% of redirects in three days, and within 3 weeks traffic returned to 90% of original.

What Does a Pre-Migration Audit Include?

Before starting development on the new site:

1. Full crawl of current site via Screaming Frog or Sitebulb. Get list of all indexable URLs with traffic from Google Search Console.
2. Export all pages with organic traffic >0 over the last 6 months — these are priority for redirects.
3. Record all external backlinks to specific pages — Ahrefs, Semrush.
4. Snapshot current positions for key queries — baseline for post-migration comparison.
5. Save Core Web Vitals from Search Console for the previous 90 days.

Table for recording:

Contact us for a detailed pre-migration audit — we will help identify all risks and create an action plan.

URL Mapping and Redirects

For projects with 200+ pages, we create a mapping table: old URL → new URL → status (301, merged with another page, deleted). Each row is verified: does the content actually migrate here?

In Laravel, redirects are handled via configuration file and middleware, not .htaccess — faster and more manageable. For WordPress → Next.js: redirects are set in next.config.js (static) and at the Nginx/CDN level for dynamic ones. Old .htaccess on shared hosting with 500+ lines of redirects is a special hell. Each redirect is checked sequentially, performance suffers. We move to Nginx map directive or Redis cache for dynamic lookup. More at Wikipedia: HTTP 301.

How to Migrate Content from Different CMSs?

WordPress → Headless CMS (Contentful, Strapi, Sanity): WordPress REST API or WP All Export to export posts, meta fields, media files. Migration script in Node.js: parse export, transform structure, upload via CMS API. Media files are reuploaded to new storage, links updated in content. Typical problem — shortcodes in WordPress content ([gallery id="123"]): need parser and transformation to new format.

1C-Bitrix → modern stack: Bitrix stores content in non-standard tables with IBLOCK_ELEMENT_PROPERTY. Direct SQL export via phpMyAdmin or Bitrix API. Transformation is the longest part due to specific Bitrix data structure.

Heavy WYSIWYG → structured content: Years of editing in FCKEditor/TinyMCE leave inline styles, non-standard tags, broken attributes. HTML sanitize + transformation to Markdown or Portable Text (Sanity) with manual check of problematic pages.

How to Preserve Technical SEO Elements During Migration?

Structured data (Schema.org) — if the old site had Product, Article, BreadcrumbList markup, they must be on the new site too. Google Search Console → Enhancement reports will show loss of rich snippets.

Sitemap XML: generated automatically, submitted to GSC a day after launch. Old sitemap remains until full reindexing.

hreflang for multilingual sites: if tags are lost during migration, conflicts between language versions in search results will start within weeks.

Open Graph and Twitter Card meta tags — often forgotten when changing template, pages stop displaying correctly when shared on social networks.

Launch and First Weeks Monitoring

DNS propagation: DNS switching takes up to 48 hours, plan launch with buffer. Cloudflare as DNS provider — propagation takes minutes, not hours.

After launch, monitor daily: Search Console → Coverage (indexing errors), Analytics → organic traffic, year-over-year comparison, crawl site for 404 errors.

First 2 weeks are critical. If traffic drops more than 30% — immediate audit of redirects and comparison with pre-migration crawl.

What the Service Includes

Results you receive:

1. Migration plan with URL mapping and redirects in Excel/Google Sheets format.
2. Configured 301 redirects at server level (Nginx/Cloudflare/Vercel).
3. Migrated content with integrity check: images, meta fields, links.
4. Structured data (Schema.org) on the new site, identical to old or improved.
5. SEO report: position trend at 1, 3, and 6 weeks after launch.
6. Coverage monitoring in Search Console with error notifications.
7. Guaranteed position retention: if traffic drops more than 15% within the first month — free audit and correction.

Timelines and Estimates

• Redesign with migration for a small site (up to 100 pages): 4–8 weeks.
• E-commerce migration with 500+ product pages: 8–16 weeks.
• Only technical migration part (redirects, metadata) without redesign: 1–3 weeks.

Cost is calculated individually based on scope.

Get a consultation for your project — we will respond within a day. Order a pre-migration audit of your site and receive a detailed proposal with a redirect plan. Contact us to discuss details.