Move your on-premise databases to SQL Azure and save time and money
Classically, organizations have been implementing database architectures on-premise in their datacenters.
With increased load and usage, organizations are facing increasingly complex operational challenges.
They need to make sure their databases are highly available, scalable to meet business needs, secure,
Operational complexity is almost always accompanied with cost. Highly available database infrastructures
require high-end hardware, software licenses and expert operations staff. All of these add to the
ever-increasing operational cost. Until now.
At first we were speculative. By storing our data in someone else's datacenter (SQL Azure) we risked
everything: Privacy, Security, Availability, etc. But cost savings were a clear advantage, so we decided
to give it a try. We were totally shocked at the cost, time and money we saved within a year.
Challenges with On-premise Database Infrastructures
In order to keep the on-premise database infrastructures in a healthy state, there are many challenges:
Scalability: On-premise database infrastructures can only scale up to the size of their
hardware infrastructure. If additional scalability is necessary, you need to scale up or scale out.
What if you scale up too much?
Patch Management: It is necessary to make sure that all updates are applied to the platform in
a timely manner.
Latest Features: On-premise database infrastructures would not have all the latest features
and capabilities. It would be necessary to upgrade the platform to the latest version in order to
gain access to these new features.
Access to Cloud Services: On-premise database infrastructures would not make the most out
of the Cloud Service offerings.
Employee Access: Employees have access to the database infrastructure only while on-premise.
Partner/Vendor Access: With on-premise database infrastructures, it is difficult to provide
access to your Platform to partners and vendors.
Our Database Migration to SQL Azure Approach
In this phase, we perform an inventory of all your database assets. Furthermore, applications using
these databases are discovered and added to the list. Some databases will be migrated easier than the
others, while some applications may require more work to migrate than others.
Here, we perform an assessment of all workloads and provide recommendations to fix databases prior
to the migration. Both parties would reach a go or no-go decision based on the assessment report.
Source schema may require conversion to work in the target SQL Azure. The required modifications are
documented and performed on a staging environment. Only when the conversion is successful will the
actual data be migrated.
This is an Iterative process whereby we apply the necessary changes to the applications, execute
functional and performance tests, and then, post data and schema migration, the target needs to be
tested to identify performance issues.
Data is synchronized between the source and the target. Later, the data is verified.
Here, we put the rollback strategy and plans for post migration.