Endrias Bridge

📊 Sizing Tiers Overview

Endrias Bridge categorizes source databases into four sizing tiers. Each tier drives host sizing, network bandwidth requirements, batch configuration, and estimated migration windows. Run the built-in DB Sizing Scan before planning any migration to confirm the correct tier.

🔧 Per-Tier Specifications

Detailed hardware and infrastructure specifications for each sizing tier.

🏠 Windows Host Requirements

The migration host is the Windows machine that runs Endrias Bridge. It acts as the orchestration layer — reading from the source database, transforming data, and writing to the target. This host must have stable, low-latency connectivity to both the source and the target simultaneously.

Operating System

• ✅
  Windows Server 2022 (Recommended) Best performance for background services; supports Large Send Offload (LSO) and RDMA for 10/25 GbE NICs.
• ✅
  Windows Server 2019 Fully supported. Use Datacenter edition if running multiple migration agents on the same host.
• ✅
  Windows 10 / 11 Pro or Enterprise (64-bit) Suitable for Small and Medium tier migrations. Not recommended for 24+ hour Large/XL migrations due to sleep/power policy interference.
• ❌
  Windows Server 2016 / Windows 10 Home — Not Recommended Server 2016 lacks ODBC Driver 18 optimizations; Windows Home lacks required Group Policy controls for network tuning.

CPU Requirements

RAM Requirements

Batch size directly scales with available RAM. Endrias Bridge holds one or more batches in memory per parallel worker simultaneously — under-provisioned RAM causes excessive swap, which is the single most common cause of Large-tier migration timeouts.

Disk Requirements

📦 Software Dependencies

The Endrias Bridge installer bundles most dependencies. The following table shows what is included versus what must be pre-installed on the migration host.

🌐 Latency & Bandwidth Requirements

Network performance is typically the primary bottleneck in large database migrations. Endrias Bridge streams data continuously — any packet loss, retransmission, or high-latency hop will compound across billions of rows and dramatically extend migration windows.

Latency Targets

Bandwidth Requirements

🔒 Firewall Port Requirements

Open the following ports on firewalls, security groups, and NSGs along the entire path from the migration host to each endpoint. Endrias Bridge initiates all connections outbound — no inbound connections to the migration host are required.

🔗 VPN / Direct Connect / ExpressRoute

For on-premises source databases migrating to AWS or Azure, a private high-throughput connection is strongly recommended for anything above the Small tier. Public internet paths introduce variable latency, packet loss risk, and egress costs.

Topology Recommendation for Large/XL Migrations

The migration host should never act as a network bridge between on-premises and cloud. It should be deployed in the cloud (same AZ/region as target) with the source connectivity delivered via Direct Connect or ExpressRoute. This minimizes intra-cloud hops from host to target.

☁ AWS RDS Target Sizing

These recommendations apply to RDS for SQL Server, MySQL, PostgreSQL, and Aurora. Sizing the RDS instance correctly before migration prevents target-side write bottlenecks.

Instance Class Recommendations

Storage Configuration

☁ Azure SQL Target Sizing

Azure SQL Database is available in DTU-based (Standard/Premium) and vCore-based (General Purpose, Business Critical, Hyperscale) purchasing models. For migration workloads, vCore Business Critical or Hyperscale is recommended for Large and XL tiers due to in-memory throughput and local SSD storage.

DTU / Premium Tier (Legacy Sizing)

vCore Model (Recommended)

💾 Storage Configuration Best Practices

⚙️ Parameter Group Tuning

Apply these parameter changes to the target database before migration begins. Endrias Bridge can automate most of these via the Pre-Migration Optimizer, but manual review is recommended for Large and XL tiers.

MySQL (RDS / Aurora MySQL)

PostgreSQL (RDS / Aurora / Azure PG)

SQL Server Target (RDS for SQL Server / Azure SQL)

🔄 Batch Size Tuning Guide

Endrias Bridge reads data from the source in discrete batches and commits them to the target. Batch size is the single most impactful configuration parameter for large migration performance. Too small wastes round-trip overhead; too large risks OOM errors and unrecoverable partial-batch failures.

🧮 Memory Formula

Use this formula to validate that your chosen batch size and worker count will fit within available RAM on the migration host. Exceeding available RAM forces Windows to page, which severely degrades throughput on Large-tier migrations.

Quick Reference: Batch Size vs. Host RAM

⚡ Parallel Table Workers

Endrias Bridge migrates multiple tables simultaneously using a configurable worker pool. The optimal number of parallel workers balances CPU utilization on the migration host against connection limits on both source and target databases.

# migration_config.json — parallel worker configuration
{
  "migration": {
    "parallel_table_workers": 8,          // CPU_cores / 2
    "batch_size": 100000,               // rows per batch
    "enable_pk_chunk": true,             // for tables > 100M rows
    "pk_chunk_size": 5000000,           // rows per PK sub-range
    "connection_pool_size": 3,           // connections per worker
    "commit_interval": 1                // commit every N batches
  }
}

✅ Pre-Migration Checklist (Large Databases)

Complete every item in this checklist before initiating a Large or Extra-Large migration. Items marked with a warning badge have caused production migration failures when skipped.

• Run DB Sizing Scan — use MigrationBridge's built-in sizing tool to confirm tier, total row count, avg row width, largest tables, and LOB column presence. Output drives all subsequent configuration decisions.
• Benchmark rows/sec on a test table — run a 1 M-row test migration against a representative table to measure actual throughput. Use: estimated_total_time = total_rows / measured_rows_per_sec. Add 20% buffer.
• Validate network latency and bandwidth — use ping + iperf3 between migration host, source, and target. Confirm < 5 ms latency and > 1 Gbps sustained throughput on the host-to-target path.
• Confirm target storage headroom Critical — provision target at source_size × 1.3 minimum. Storage-full mid-migration requires a full restart from the last checkpoint.
• Disable non-critical indexes on target before migration — Endrias Bridge automatically disables and re-enables non-clustered indexes. Confirm this behavior is enabled in migration_config.json via "disable_target_indexes": true.
• Schedule during off-peak hours — for databases still serving read traffic, coordinate the migration window with application owners. Source reads during migration may degrade source query performance.
• Set SQL Server MAXDOP=1 on source during migration Large/XL Only — prevents the source query optimizer from issuing parallel scans that compete with Endrias Bridge reads. Run: EXEC sp_configure 'max degree of parallelism', 1; RECONFIGURE;
• Switch SQL Server source/target to Bulk-Logged recovery SQL Server only — minimally logs bulk operations, reducing transaction log growth by up to 80%. Run: ALTER DATABASE [YourDB] SET RECOVERY BULK_LOGGED; Restore to FULL after migration.
• Verify migration host disk space — confirm temp staging directory has sufficient free space per tier specification. Large checkpointing uses disk-based resume files.
• Test target connectivity with credentials — use MigrationBridge's built-in Connection Test before starting. A failed authentication at hour 30 of a 48-hour migration is avoidable.
• Disable target autovacuum (PostgreSQL targets) — set autovacuum = off for the target database during migration. Schedule a full VACUUM ANALYZE immediately after completion.
• Confirm firewall / security group rules — test all ports listed in the Firewall Ports section from the migration host using Test-NetConnection (PowerShell) or telnet.
• Take a pre-migration snapshot of the target — for RDS: create a manual snapshot before starting. For Azure SQL: note the PITR point-in-time before migration begins. This is the rollback point.
• Notify stakeholders and set maintenance window — for Large migrations, ensure application teams, on-call DBAs, and leadership are aware of the window, expected duration, and rollback triggers.

📄 SQL Server Source Preparation

Run these T-SQL commands on the SQL Server source database before starting a Large or XL migration. Reverse all changes after migration is validated.

-- ─────────────────────────────────────────────────────────────────────────
-- SQL Server Pre-Migration Configuration
-- Run on SOURCE database before starting Endrias Bridge migration
-- ─────────────────────────────────────────────────────────────────────────

-- 1. Limit parallelism on source to prevent competing parallel scans
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;

-- 2. Switch source to Bulk-Logged to reduce log file growth
ALTER DATABASE [YourSourceDB] SET RECOVERY BULK_LOGGED;

-- 3. Reduce lock escalation threshold to protect source OLTP traffic
ALTER DATABASE [YourSourceDB] SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [YourSourceDB] SET READ_COMMITTED_SNAPSHOT ON;

-- 4. Verify source configuration
SELECT name, recovery_model_desc, snapshot_isolation_state_desc,
       is_read_committed_snapshot_on
FROM sys.databases
WHERE name = 'YourSourceDB';

-- ─────────────────────────────────────────────────────────────────────────
-- POST-MIGRATION: Restore original settings
-- ─────────────────────────────────────────────────────────────────────────

-- Restore MAXDOP to original value (check your baseline before migration)
EXEC sp_configure 'max degree of parallelism', 0; -- 0 = SQL Server default (auto)
RECONFIGURE;

-- Restore full recovery model (important for DR / backup compliance)
ALTER DATABASE [YourSourceDB] SET RECOVERY FULL;

-- Take a log backup immediately after switching back to FULL
BACKUP LOG [YourSourceDB]
    TO DISK = N'NUL';  -- Replace with actual backup path in production

☁ AWS-Specific Guidance

EC2 Migration Host in Same AZ as RDS Target

Deploy the EC2 migration host in the same Availability Zone as the RDS target instance. Cross-AZ traffic incurs additional latency (typically 1 – 3 ms) and data transfer costs ($0.01/GB). For a 1 TB migration, same-AZ saves ~$10 in transfer costs and meaningfully reduces migration time.

• ✅
  Use Enhanced Networking (ENA) All modern EC2 instance types (c6i, r6i, m6i) support Enhanced Networking by default. Provides up to 25 Gbps network throughput and significantly lower latency than legacy instance types. Verify with: ethtool -i eth0 — should show ena driver.
• ✅
  Place EC2 and RDS in same VPC and subnet Use a security group reference (not IP CIDR) for the RDS inbound rule pointing to the EC2 instance's security group. This survives instance replacement and IP changes.
• ⚠
  Use S3 Staging for migrations > 500 GB For Extra-Large tier, configure Endrias Bridge to stage batches to S3 (same region) before loading into RDS. This decouples extraction from loading, allows parallel re-loading of failed ranges, and provides a durable checkpoint store. Use a VPC Gateway Endpoint to avoid internet egress costs.
• ✅
  Use Placement Groups for 25 Gbps throughput For XL migrations requiring maximum bandwidth, place the EC2 migration host in a cluster placement group in the same AZ. Combined with a 25 Gbps-capable instance type (e.g., r6i.8xlarge), this maximizes intra-AZ network bandwidth.
• ✅
  CloudWatch monitoring during migration Enable Enhanced Monitoring on RDS (1-second granularity). Create CloudWatch alarms for: WriteIOPS saturation, FreeStorageSpace below 20%, DatabaseConnections approaching max, and CPUUtilization above 85%.

Recommended EC2 Instance Types for Migration Host

☁ Azure-Specific Guidance

Migration Host in Same Region as Azure SQL

Deploy the Azure VM migration host in the same Azure region as the target Azure SQL Database or Managed Instance. Unlike AWS (AZ-level), Azure SQL zone redundancy operates within a region — intra-region latency to Azure SQL from a VM in the same region is typically < 1 ms.

• ✅
  Use VNet Integration for Private Endpoint Configure Azure SQL Private Endpoint so all traffic between the migration host VM and Azure SQL stays on the Azure backbone (no public internet). Place the VM in a subnet with a UDR (User Defined Route) pointing to the Private Endpoint subnet.
• ✅
  Use ExpressRoute for on-prem sources > 100 GB For on-premises SQL Server sources migrating to Azure SQL, provision an ExpressRoute circuit with at least 2 Gbps bandwidth. ExpressRoute delivers < 5 ms latency from on-prem to Azure SQL via Microsoft peering — required for sustained Large-tier throughput.
• ✅
  Use Azure Blob Staging for XL migrations Similar to S3 staging on AWS, configure Endrias Bridge to stage to Azure Blob Storage (same region) for Extra-Large migrations. Use a VNET Service Endpoint or Private Endpoint for Blob to avoid internet egress. Cost: ~$0.0184/GB storage + $0.0025/10K write operations.
• ✅
  Accelerated Networking on Azure VM Enable Accelerated Networking (SR-IOV) on the migration host VM. Supported on most D-series, E-series, and F-series VMs. Reduces CPU overhead for network I/O and delivers consistent low-latency throughput. Enable via: Azure Portal → VM → Networking → Enable Accelerated Networking.
• ⚡
  Azure Monitor alerts during migration Set Azure Monitor alerts for the target Azure SQL: DTU/vCore consumption > 85%, storage consumption > 80%, connection failures > 5/min, and log write throughput approaching tier limit. Use Action Groups to alert on-call DBAs via email/SMS/PagerDuty.

Recommended Azure VM SKUs for Migration Host

🏠 Hybrid & On-Premises Guidance

VPN Configuration

When using a site-to-site VPN between on-premises and cloud, follow these requirements to maintain throughput during multi-day Large-tier migrations.

On-Premises Migration Host

If the migration host must reside on-premises (rather than cloud-side), ensure it has direct high-speed LAN access to the source database and dedicated WAN connectivity to the cloud target.

• ✅
  Migration host on same LAN segment as source database The host-to-source path should be on the same 10 GbE switch fabric. Avoid routing through WAN links, proxy servers, or DPI appliances for the source read path.
• ✅
  Dual NICs for large migrations Use a dedicated NIC for source reads and a separate NIC for cloud writes. Prevents source traffic from competing with target upload bandwidth on a single NIC queue.
• ⚠
  UPS and power management Ensure migration host is on a UPS circuit. Configure Windows power plan to High Performance (prevents CPU throttling). Disable sleep and hibernate. A power event mid-migration does not corrupt data (Endrias Bridge uses durable checkpoints) but will require restart from last checkpoint.