Database movement operations home page

Database movement operations are a suite of self-service actions that can be used as part of Data Application Lifecycle Management (also referred to as DataALM). These actions provide structured processes for common implementation scenarios such as golden configuration promotion, debugging/diagnostics, destructive testing, and general refresh for training purposes.

In this article, you will learn how to use database movement operations to perform refresh, export, import, and various flavors of point-in-time restore.

Database movement scenarios and quick start guides

The following table shows the various scenarios that are supported and a link to a quick start guide for each scenario.

Source environment	Target environment	Quick start guide	Available via API	Tutorials
Production	Sandbox	Refresh database	Create refresh	Refresh for training purposes Debug a copy of the production database
Sandbox	Production	Refresh database	Not supported	Golden configuration promotion
Sandbox	Sandbox	Refresh database	Create refresh	Refresh for training purposes
Sandbox	DevTest	Export a database	Create export	Export a copy of the standard user acceptance testing (UAT) database
DevTest	Sandbox	Import a database	Not supported	Golden configuration promotion
Production	DevTest	Not directly supported	Not supported	Recommend Export a copy of the standard user acceptance testing (UAT) database
Sandbox point-in-time	Sandbox	Point-in-time restore (PITR)	Not supported	Destructive testing
Production point-in-time	Sandbox	Point-in-time restore of the production database to a sandbox environment	Not supported	Destructive testing

Important

Database movement operations are very lengthy operations. The amount of time these operations take varies by data volume, schema complexity, and whether the target of the operation is a flat file, like a .bacpac file in the case of the export operation. In general, these operations can take up to 24 hours to complete, and during the operation there is no way to cancel. In addition, if the target of the operation is an environment like in the production to sandbox scenario, the sandbox environment will go offline at an undetermined time, when the database copy operation has completed, but before the database synchronization steps begin. This will happen with no warning to end users in the environment. As result, it is best to schedule these types of operations during non-business hours.

Database Movement API

The Database Movement application programming interface (API) lets you integrate several of the previously mentioned database movement operations into your overall ALM process. In addition, by using the API together with your preferred scheduling engine, you can build recurrence into the process, so that it runs daily or on demand.

For more information about about the Database Movement API, see the following topics:

• Overview
• Versioning and support
• Authentication
• Throttling
• Reference