Application & Infrastructure Migration

We handle database migrations (MySQL to PostgreSQL, MongoDB to Supabase, Firestore to PostgreSQL), cloud migrations (bare-metal or Heroku to AWS/GCP/Azure), framework migrations (PHP or Ruby on Rails to Next.js, REST to GraphQL), and infrastructure migrations (manual deploys to Kubernetes, Terraform-managed environments). Each migration type has its own risks and techniques — we apply the right approach for the specific transition.

The core technique is running old and new systems in parallel during a validation window. For database migrations we use change data capture (CDC) or dual-write patterns to keep both databases in sync during this period, allowing an instant rollback if something goes wrong. DNS-level cutover with a short TTL and a tested rollback plan means the actual downtime window for most migrations is under 5 minutes.

Before, during, and after migration we run integrity checks: row counts by table, hash verification of critical records, and referential integrity tests for foreign key relationships. For large datasets we migrate in batches and verify each batch before proceeding. We never truncate or drop the source database until integrity checks in the target have passed and the application has been validated in production.

Every migration plan includes a specific rollback trigger condition (e.g. error rate above 1% or data validation fails) and a time-boxed rollback decision (e.g. if not confirmed stable within 30 minutes, roll back automatically). Rollback means pointing traffic back to the old system — which is still running and in sync. We do not cut the cord on the source until the new system has been stable for an agreed period.

Small migrations (a single service or database under 10GB) take 2–4 weeks end to end including planning, testing, and cutover. Large or complex migrations (multi-service, terabyte-scale data, compliance requirements) take 2–4 months. The testing and validation phase is never rushed — it is where most migration failures originate. We provide a detailed timeline after the assessment phase.

We use a strangler-fig pattern: rather than rewriting the entire application at once, we route individual features or endpoints to the new system progressively. Traffic starts at 0% on the new system, increases as confidence grows, and reaches 100% only after all features have been validated. The old system is kept alive until the new one is fully stable. This approach eliminates the risk of a big-bang cutover.

Yes, with care. User data migration requires handling PII compliantly (GDPR/CCPA), and password migration is particularly sensitive because hashed passwords cannot always be transferred between systems using different hashing algorithms. We implement forced password resets on first login when hash migration is not possible, communicate clearly with users, and ensure the experience is smooth even for users who have not logged in for months.

Yes — this is one of our most common migration types. We move Heroku apps to Railway, Render, Fly.io, or AWS depending on your requirements and budget. The migration includes containerising the application, porting Heroku-specific add-ons (Postgres, Redis, Sendgrid) to equivalent services, and setting up CI/CD pipelines equivalent to the Heroku git-push workflow your team is used to.

Schema migrations between different database engines (e.g. MySQL to PostgreSQL) require data type mapping, constraint re-expression, and sometimes stored procedure rewrites. We produce a schema mapping document, generate the target DDL, run a test migration with production data on a staging environment, and validate that the application works correctly against the new schema before scheduling the production cutover.

SEO is a first-class concern in any site migration. We implement 301 redirects for all changed URLs, preserve the sitemap, transfer structured data markup, monitor Google Search Console for crawl errors post-migration, and set canonical URLs correctly. We track organic traffic and rankings during the stabilisation period and respond quickly to any unexpected drops.

Secrets are never copied into migration scripts or stored in version control. We use a secrets manager (AWS Secrets Manager, Vault, Doppler) to inject credentials at runtime during both the parallel-run period and post-cutover. We also audit the old system for hard-coded credentials before decommissioning — it is common to find credentials that were never rotated and should be invalidated before the old system goes dark.

Yes. We stay engaged for a stabilisation period after cutover — typically 2–4 weeks — monitoring for issues, responding to incidents, and fine-tuning performance in the new environment. We also deliver a migration retrospective document covering what went well, what was difficult, and any technical debt inherited by the new system. After stabilisation we hand over to your team or transition to a maintenance retainer.