About Expertise Work Managed Apps
Business Website Online Store Sales CRM Team Drive Online Academy Newsletter System Booking System Shared Inbox Knowledge Base Short Links Business Manager Photo Gallery Survey Platform Community Forum Project Boards Estate Agency Car Workshop Restaurant Clinic Photography Studio
AWS
Assess & advise Build & migrate Automate & operate Secure & comply Urgent & go-live
Projects
Hosted Monitoring & Dashboards Self-Hosted Observability Stack Bulk Document Data Extraction Email Deliverability Diagnosis & Repair SEO Migration Recovery AWS Security Review VPS Hardening & ModSecurity Cloud Architecture & Resilience Review SSL & Server Configuration Container Security Review DNS & Email Troubleshooting DevOps Deployment & Rollback Review WordPress Hardening Retainer Data Pipeline Rerun Review Metric Reconciliation
Free Tools
Website Health Check Email Domain Health Check DNS Health Check SSL Certificate Checker Redirect Chain Checker Robots.txt Checker XML Sitemap Validator Docker Compose Checker WordPress Security Check AWS IAM / S3 Policy Checker Domain Registration Lookup Uptime Monitoring Trial Downtime Cost Calculator AWS Cost Estimator Cloud Architecture Self-Assessment DevOps Engagement Builder Self-Managed VPS vs Managed AWS
Blog Certifications Hire Me

Database Migration to Amazon RDS

PostgreSQL or MySQL onto RDS, with the cutover rehearsed and a way back.

Price and scope

From $549

Typically $549–$1,599, fixed in writing before anything starts.

3–7 days
Working days, counted from the moment I have access — not from the day you agree.

What moves it up

  • More than about 50 GB, where the copy itself stops fitting in the window
  • A downtime allowance measured in minutes rather than hours
  • A major version jump at the same time as the move, which is two migrations wearing one hat
What a database dump does not carry acrossA self-managed PostgreSQL server beside an Amazon RDS instance, comparing four settings that do not travel with the data: collation, timezone, installed extensions and max_connections. All four differ on the RDS side.the rows arrive. these four do not follow them.SOURCE · SELF-MANAGEDTARGET · AMAZON RDSlc_collate en_US.UTF-8lc_collate Ctimezone Africa/Cairotimezone UTCextension pg_cronpg_cron unavailablemax_connections 500max_connections 87
Database Migration to Amazon RDS

What actually goes wrong

The dump restores. Everyone treats that as the migration working, and it is the least interesting thing that happens all week. What breaks afterwards is the difference between the database the application was written against and the one it is now talking to: a different default collation quietly changing how ORDER BY sorts, a timezone set to UTC where the old box was on local time, an extension the schema depends on that RDS will not install, and a max_connections derived from instance class rather than from the number your connection pool was configured for two years ago.

How I find it

  • pg_dump --schema-only on both sides, diffed, before anyone celebrates
  • SELECT name, setting FROM pg_settings WHERE name IN ('lc_collate','timezone','max_connections')
  • aws rds describe-db-parameters --db-parameter-group-name <group> — against the old server config, line by line
  • A rehearsed cutover against a restored copy, timed, before the real one is scheduled

What you get

  • The target RDS instance, parameter group and subnet group, built and documented
  • A rehearsed cutover run end to end against a copy, with the elapsed time measured rather than estimated
  • A written cutover runbook, including the rollback and the point after which rollback stops being possible
  • Row counts and a schema diff from both sides, as the evidence the data arrived intact
  • Automated backups and point-in-time recovery configured, with one restore performed and timed

Questions

How much downtime should I plan for?

I will not give you a number before the rehearsal, and you should be suspicious of anyone who does. The rehearsal against a restored copy produces the real figure, and the maintenance window gets booked after that rather than before it.

Can you migrate with no downtime at all?

Sometimes, using logical replication to keep the target in step until you cut over. It costs more, it needs the source to be a version that supports it, and it is worth it when minutes of downtime cost you real money. When they do not, a short planned window is simpler and has fewer ways to go wrong.

What happens to the old database?

It stays running, untouched and still holding your data, until you tell me to stop it. Nothing is deleted as part of this work. The rollback is only real for as long as the old instance is still there.

Will my application need code changes?

Usually just the connection string and the TLS settings. Occasionally more, when the schema leans on something RDS does not offer — a filesystem-backed extension, or a superuser action the managed service does not grant. I check for that before the work starts, not during the cutover.

AWS Architecture Review

What your account actually looks like, what breaks first, and what it is costing you to keep it that way.

From $299 2–4 days

Want this done?

Tell me what you are running and I will come back with a fixed price and a date. If it turns out you do not need this, I will say that instead.

Prefer to talk? Book a free call ↗  ·  Or hire me on Upwork ↗  ·  Typical reply within one business day.

When I answer

Sunday to Thursday, 09:00–18:00 EET. Outside that I will still look, but I will not promise a time.

No 24/7 desk, and I will not pretend otherwise

One person, one time zone. If round-the-clock cover is what you need, you need a team, and I will say so rather than sell you a plan that cannot deliver it.

Your AWS bill stays yours

You pay Amazon directly and you keep control of the account. Nothing here resells your infrastructure or sits between you and your own billing.

A price that starts with "from" is a starting price

Every service page lists exactly what pushes a quote above it, before you ask. You get a fixed number in writing before any work begins.