• EnterpriseDB can be run on any of the three major public cloud provid-
ers and provides the ability to run unmodified PL/SQL, facilitating faster
migrations without the need for as much refactoring.
The evaluation of cloud vendors and target database platforms should be done
in parallel so that tradeoffs and capabilities can be considered when making
platform and database choices. The ultimate decision for targets has both
financial and technical considerations. Often the public cloud vendors will
provide access to subsidized tools to facilitate adoption as well as credits to
support the initial build out of workloads on their cloud.
Identify Data Migration Method
After a target cloud platform and database has been selected, the method for
migration of data must be chosen. The most critical question to this selection
is, “how much downtime can I tolerate when I cutover?” This is a place where
both the cloud vendors as well as third parties provide solutions that can be
leveraged, depending on availability needs.
• Low Tolerance for Downtime – Tools from companies like Attunity can
facilitate the replication of data while keeping multiple databases in sync,
enabling rapid application cutover where downtime needs to be kept to a
minimum.
• Moderate Tolerance for Downtime – Where a little more tolerance is
available, the cloud platform vendors provide their own tools to facilitate
both schema conversion, as well as data migration. AWS offers the Data-
base Migration Service, and Microsoft the Assessment and Planning
Toolkit and SQL Server Migration Assistant.
• High Tolerance for Downtime – AWS provides Snowball for environ-
ments where high latency is acceptable to facilitate the movement of
large amounts of data that would overwhelm an enterprise’s upstream
bandwidth.
Dry Run
With the high levels of availability required on many business systems, it is not
a simple cutover. Particularly in complex environments where databases are
receiving feeds from many sources and providing exports to others, testing is
critical to ensure success. Executing a dry run prior to the formal migration
will allow staff to validate checklists, validate skills and most importantly, test
roll back procedures in the event the migration fails. These dry-runs enable the
team to get comfortable working together in the various aspects of application,
infrastructure, security and database operations that must execute in unison
for the production cut over.
The dry-run is not a one-time event. It should be executed at a minimum, once
per application and database being migrated, but could reasonably be done
several times to ensure proper process and roll back procedures.
18 | THE DOPPLER | SPRING 2017