Automated Data Integrity Verification After Migration

Our company is engaged in the development, support and maintenance of sites of any complexity. From simple one-page sites to large-scale cluster systems built on micro services. Experience of developers is confirmed by certificates from vendors.

Development and maintenance of all types of websites:

Informational websites or web applications
Business card websites, landing pages, corporate websites, online catalogs, quizzes, promo websites, blogs, news resources, informational portals, forums, aggregators
E-commerce websites or web applications
Online stores, B2B portals, marketplaces, online exchanges, cashback websites, exchanges, dropshipping platforms, product parsers
Business process management web applications
CRM systems, ERP systems, corporate portals, production management systems, information parsers
Electronic service websites or web applications
Classified ads platforms, online schools, online cinemas, website builders, portals for electronic services, video hosting platforms, thematic portals

These are just some of the technical types of websites we work with, and each of them can have its own specific features and functionality, as well as be customized to meet the specific needs and goals of the client.

Showing 1 of 1All 2062 services
Automated Data Integrity Verification After Migration
Medium
~2-3 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1358
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    956
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    947

Automated Data Integrity Checks After Migration

Data migration is always stressful. You've moved thousands of records, but are you sure nothing was lost? Relations intact? URLs not broken? Without automated checks, you're guessing. Manual spot-checking is a lottery: you verify 5% of records, but errors hide in the remaining 95%. Especially with nested comments, meta fields, or SEO tags — a single miss can cost traffic or functionality.

Recently we worked with a client: 10,000 posts, 50,000 comments migrating from WordPress to Laravel. Manual spot-checking (3 days, two engineers) found 30 broken links. Automated checks — in 1 day — uncovered 200 lost comments, 5% duplicate URLs, and 150 pages missing SEO titles. The difference is clear: automation is 3× faster and 20× more accurate.

We are a team of engineers with 5+ years of experience in complex migrations. We've developed a script set that gives a full integrity picture in 1–2 days. The scripts adapt to your CMS and database structure — whether it's PostgreSQL, MySQL, or MongoDB.

Why Automated Integrity Checks Are Essential

Manual spot-checking is inefficient. You risk losing 2–5% of records (especially nested comments or meta fields), breaking parent-child relations, creating duplicate URLs, and leaving SEO tags missing — all of which hurt ranking. Automation eliminates these risks. Compare the two approaches:

Characteristic Manual Check Automated (Our Approach)
Coverage Random sample 100% of records
Time 3–5 days 1–2 days
Error miss rate ~30% <1%
Documentation None Detailed HTML/JSON report
Repeatability One-off Multiple runs (CI/CD possible)

Typical consequences of missed errors:

Error Type Consequence
Lost records Content loss, functionality degradation
Broken relations 404 errors, non-working comments
Duplicate URLs Search engine penalties, traffic loss
Missing SEO tags Ranking drops

What We Check: Detailed Checklist

Our engineers have implemented scripts for five key checks. Each comes with concrete metrics.

How Checksum Verification Works

We compare aggregated MD5 over critical fields. It detects even minor changes in data. Source: Wikipedia, MD5.

def checksum_check(source_db, target_db):
    """Compare checksums over critical fields"""

    # PostgreSQL
    source_hash = source_db.query_one("""
        SELECT md5(string_agg(
            md5(id::text || coalesce(email,'') || coalesce(slug,'')),
            ',' ORDER BY id
        )) as hash
        FROM articles
        WHERE status = 'published'
    """)

    target_hash = target_db.query_one("""
        SELECT md5(string_agg(
            md5(legacy_id || coalesce(email,'') || coalesce(slug,'')),
            ',' ORDER BY CAST(legacy_id AS INTEGER)
        )) as hash
        FROM articles
        WHERE status = 'published'
    """)

    return source_hash == target_hash

Record Count Verification

We compare record counts per content type, considering status filters (published/draft). Example code:

class MigrationValidator:
    def __init__(self, source_db, target_db):
        self.source = source_db
        self.target = target_db
        self.results = []

    def check_counts(self):
        tables = [
            ('posts', 'articles', "status='publish'", "status='published'"),
            ('users', 'users', None, None),
            ('comments', 'comments', "approved=1", "status='approved'"),
            ('categories', 'categories', None, None),
        ]

        for src_table, tgt_table, src_where, tgt_where in tables:
            src_count = self.source.count(src_table, src_where)
            tgt_count = self.target.count(tgt_table, tgt_where)

            status = 'OK' if src_count == tgt_count else 'MISMATCH'
            self.results.append({
                'check': f'count_{src_table}',
                'status': status,
                'source': src_count,
                'target': tgt_count,
                'diff': tgt_count - src_count
            })

Referential Integrity Check

We look for orphan records: articles without an author, comments without a parent article or parent comment.

def check_referential_integrity(target_db):
    issues = []

    # Articles without author
    orphaned_posts = target_db.query("""
        SELECT a.id, a.title FROM articles a
        LEFT JOIN users u ON a.author_id = u.id
        WHERE a.author_id IS NOT NULL AND u.id IS NULL
    """)
    if orphaned_posts:
        issues.append(f"Articles without valid author: {len(orphaned_posts)}")

    # Comments pointing to non-existent posts
    orphaned_comments = target_db.query("""
        SELECT c.id FROM comments c
        LEFT JOIN articles a ON c.post_id = a.id
        WHERE a.id IS NULL
    """)
    if orphaned_comments:
        issues.append(f"Orphaned comments: {len(orphaned_comments)}")

    # Child comments without parent
    broken_threads = target_db.query("""
        SELECT c.id FROM comments c
        LEFT JOIN comments p ON c.parent_id = p.id
        WHERE c.parent_id IS NOT NULL AND p.id IS NULL
    """)
    if broken_threads:
        issues.append(f"Comments with missing parent: {len(broken_threads)}")

    return issues

URL Availability Check

We asynchronously check every published URL for HTTP 200, 404, 500, and redirect chains.

import asyncio
import aiohttp

async def check_urls(urls, base_url, concurrency=20):
    errors = {'404': [], '500': [], 'redirect_chain': []}
    semaphore = asyncio.Semaphore(concurrency)

    async def check_one(session, path):
        async with semaphore:
            url = f"{base_url}{path}"
            try:
                async with session.get(url, allow_redirects=True) as resp:
                    if resp.status == 404:
                        errors['404'].append(path)
                    elif resp.status >= 500:
                        errors['500'].append(path)
                    elif len(resp.history) > 2:
                        errors['redirect_chain'].append(f"{path} ({len(resp.history)} redirects)")
            except Exception as e:
                errors['500'].append(f"{path} (error: {e})")

    async with aiohttp.ClientSession() as session:
        tasks = [check_one(session, url) for url in urls]
        await asyncio.gather(*tasks)

    return errors

# Run
urls_to_check = get_all_published_urls(target_db)
results = asyncio.run(check_urls(urls_to_check, 'https://new-site.com'))

SEO Metadata Check

We look for pages missing title/description, duplicate titles, and missing canonical tags.

def check_seo_completeness(target_db):
    issues = []

    # Pages without title
    no_title = target_db.query("""
        SELECT slug FROM articles
        WHERE (seo_title IS NULL OR seo_title = '')
        AND status = 'published'
    """)
    if no_title:
        issues.append(f"Pages without SEO title: {len(no_title)}")

    # Pages without meta description
    no_desc = target_db.query("""
        SELECT slug FROM articles
        WHERE (seo_description IS NULL OR seo_description = '')
        AND status = 'published'
    """)
    if no_desc:
        issues.append(f"Pages without meta description: {len(no_desc)}")

    # Duplicate titles
    dup_titles = target_db.query("""
        SELECT seo_title, COUNT(*) as count FROM articles
        WHERE status = 'published'
        GROUP BY seo_title
        HAVING COUNT(*) > 1
    """)
    if dup_titles:
        issues.append(f"Duplicate SEO titles: {len(dup_titles)} groups")

    return issues
Example CI/CD Integration

We package the checks into a Docker image. Your pipeline runs the container, passing environment variables for database connections. Results are published as artifacts in JUnit XML format.

Our Process

  1. Schema Analysis — Study source and target database structures, identify critical tables and fields.
  2. Script Adaptation — Tailor checks to your specific stack (PostgreSQL/MySQL, CMS).
  3. Run & Collect Results — Execute scripts, generate report in HTML/JSON/JUnit.
  4. Analysis & Recommendations — Break down each failed test, propose remediation plan.
  5. CI/CD Deployment (optional) — Package checks into Docker container, connect to pipeline.

What's Included

  • Check scripts (Python, configurable for your project).
  • Detailed report with results table and list of problematic records.
  • Remediation recommendations for each error.
  • Documentation on running and interpreting results.
  • Training for one client engineer.
  • Guarantee: If after fixes a discrepancy is found, we refine the script at no extra cost.

Estimated Timeline

Script development and final report: 1–2 working days. Complexity depends on number of tables and data volume. Cost is calculated individually — contact us for an accurate estimate.

Why Choose Us

  • 5+ years of migrations: from WordPress to custom Laravel solutions.
  • 200+ data transfer projects.
  • Certified engineers in PostgreSQL and Docker.
  • Result guarantee: all checks run on a test environment before main execution.

Request a consultation on post-migration data integrity — we'll assess the scope and recommend the optimal set of checks. Contact us to get a detailed work plan and cost estimate.

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:

Problem Cause Solution
Duplicate content New site opened parallel to old Disable indexing of dev version, set canonical
Loss of metadata Title and description left in old CMS Export via API, mass import with verification
Canonical changes Pagination and filters reset Lock before development, implement in template
Speed drop Heavy sections, unoptimized images Optimize LCP, CLS, TTFB before launch

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:

Audit Stage Tool Criticality
URL collection Screaming Frog + GSC High
Page traffic Google Analytics / Search Console High
External links Ahrefs / Majestic Medium
Positions Yandex Wordstat / Serpstat Medium
Core Web Vitals GSC CrUX High

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.

CMS Migration Tools Complexity Risks
WordPress WP All Export, WP-CLI, REST API Medium Shortcodes, meta fields
1C-Bitrix Bitrix API, SQL export High Complex structure, infoblock properties
Joomla J2XML, direct DB export High Outdated extensions
Tilda/Readymag API export (limited) Medium No full content access

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.

Launch checklist (spoiler)
  • [ ] All 301 redirects work and do not form chains
  • [ ] Sitemap submitted to GSC and Yandex.Webmaster
  • [ ] Canonical tags set on all pages
  • [ ] Open Graph / Twitter Card display checked
  • [ ] robots.txt and noindex meta tags adjusted
  • [ ] Core Web Vitals in green zone (LCP <2.5s, CLS <0.1, INP <200ms)

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.