On-premises databases moved to Amazon RDS, rehearsed until the cut-over is routine

Amazon RDS takes patching, backups and failover off your team, but it is not the server you had: there is no operating system to log in to, and some features work differently. We check what your database relies on, script the move so every rehearsal runs the same way, and hand over a managed database your team can run.

Book a strategy call See case studies

What we cover

Is RDS the right targetWhat changes when a database moves to RDS
How the move runsA scripted migration, rehearsed on a copy of your data
Cut-over and afterThe night of the move, and the weeks after it
ProofOracle to Amazon RDS for a national nonprofit

Is RDS the right target

What changes when a database moves to RDS

On RDS, AWS runs the operating system, the storage and the database software. You get automated backups, point-in-time restore, patching in a maintenance window you choose and, with Multi-AZ, a standby copy in a second Availability Zone. In exchange you give up the server: there is no remote session on the host, no SYSDBA in Oracle and no sysadmin role in SQL Server, and file access goes through the procedures RDS provides.

Most applications never notice. Some do: jobs that call operating-system scripts, database links to servers that stay on premises, external tables that read local files, and monitoring agents installed on the database host. The assessment lists every one of these in your database, with what replaces it, before you decide. Sometimes the better answer is Amazon EC2, where you keep the server, or Aurora, where PostgreSQL or MySQL compatibility opens up more of the managed service.

What we do

An inventory of the features, jobs and links your database depends on
Engine, edition, instance class and storage sized from your own workload
License options compared: bring your own, or license included where the edition allows it
A written recommendation for RDS, Aurora or EC2, and the reasons

How the move runs

A scripted migration, rehearsed on a copy of your data

For an Oracle database the usual route is Oracle Data Pump: export the schemas, copy the dump files to an Amazon S3 bucket, bring them into the RDS instance through its S3 integration, create the tablespaces and users, and import. For SQL Server it is a native backup restored from S3. Done by hand, each step is a chance to miss a grant, a tablespace or a synonym, and the mistakes show up only at the end.

So we script it. The same scripts build the target, move the data, recompile invalid objects and compare object and row counts between source and target, and they log every step. We run them against a copy first, fix what fails and run them again until the rehearsal is clean and its timing is known. When the outage has to be shorter than an export and import allows, we keep the target in step with AWS Database Migration Service or Oracle GoldenGate and cut over once it has caught up.

What we do

Target instance, parameter group and option group built from code
Data Pump, or native backup and restore, through Amazon S3
Objects, grants and row counts validated after every run
A log of every step, so a failed run says where and why

Cut-over and after

The night of the move, and the weeks after it

Cut-over follows a written runbook: freeze changes, take the final export or let the final sync catch up, validate, point the applications at RDS and keep the source read-only until the business signs off. The way back is written down too, and tested in rehearsal, so nobody has to invent it in the middle of the night.

After the move we tune what changed with the platform: instance class, storage type and throughput, parameter groups and the queries that behave differently on the new instance. We set up Amazon CloudWatch alarms so your team sees load, storage and replication problems before users do, and we hand over the scripts and the runbook, so the next refresh or the next database follows the same path.

What we do

A cut-over runbook with a tested way back
The source kept read-only until sign-off
Instance, storage and parameters right-sized after go-live
Monitoring and alarms in Amazon CloudWatch

Proof

Oracle to Amazon RDS for a national nonprofit

A national nonprofit's on-premises Oracle database had become hard to maintain and to scale. We planned the move with automated workflows and validation tests, migrated it to Amazon RDS for Oracle with minimal disruption, and left the team a repeatable process for future changes. The case study below has the detail.

Moving more than databases? Our cloud migration page covers servers, file shares and applications, and AWS Database Migration Service has its own page, for moves that need continuous replication or a change of engine.

Case studies

AWS RDS Migration in practice

Client names are withheld. We are happy to share details on a call.

All case studies

Delivered
On-prem → Amazon RDS
Nonprofit
Cloud Consulting
Oracle from on-premises to Amazon RDS for a national nonprofit
The nonprofit's on-premises Oracle database had become hard to maintain and scale. We planned the move with automated workflows and validation tests, migrated to Amazon RDS for Oracle with minimal disruption and left a repeatable process for future changes.
- Automated, tested migration
- Less day-to-day database upkeep
Read the case study →

Questions

Common questions

Which databases can move to Amazon RDS?

RDS runs Oracle, Microsoft SQL Server, PostgreSQL, MySQL, MariaDB and IBM Db2, and Aurora offers editions compatible with PostgreSQL and MySQL. Most of our RDS work is Oracle moving to Oracle on RDS. Changing engine at the same time, Oracle to PostgreSQL for example, is a larger project, and we plan it separately.

How long will the database be unavailable?

It depends on the size of the data and the method. An export and import keeps the application stopped for as long as the final export, copy and import take, which the rehearsal measures. When that is too long, changes are replicated continuously and the outage shrinks to the time it takes to stop writes and repoint the applications. You get the measured figure before you choose a date.

Do we need new Oracle licenses?

Not necessarily. RDS for Oracle runs with licenses you already own, or, for Standard Edition Two, with the license included in the hourly price. Which is cheaper depends on what you own and how large the instance is, so the assessment compares both. Your own Oracle agreements decide what you may move; we can go through them with you.

What can we not do on RDS that we do today?

You cannot log in to the server, install software on it or use the highest administrative roles, and some features are unavailable or work through AWS procedures instead. Operating-system scripts, local file access and some database options are the usual surprises. The assessment lists each one that applies to your database and what replaces it.

Is Aurora a better choice than RDS?

For PostgreSQL and MySQL workloads it often is, because Aurora's storage grows and replicates on its own. For Oracle and SQL Server it is not an option without changing engine. We recommend one or the other from your workload and costs, not by default.

From the blog