--- title: "How To: Move Databases in Planning Analytics" description: "# How to Move a Database Between Environments in IBM Planning Analytics Moving a [Planning Analytics](https://www.aramar.co.uk/ibm-planning-analytics/) database between environments is a routine task for many administrators. And following a consistent process helps minimise downtime and reduces the risk of losing…" url: "https://www.aramar.co.uk/knowledge-share/ibm-planning-analytics/moving-databases-in-planning-analytics/" updated: "2026-06-29" category: IBM Planning Analytics --- # How To: Move Databases in Planning Analytics # How to Move a Database Between Environments in IBM Planning Analytics Moving a [Planning Analytics](https://www.aramar.co.uk/ibm-planning-analytics/) database between environments is a routine task for many administrators. And following a consistent process helps minimise downtime and reduces the risk of losing work. This guide outlines a proven approach to moving databases and Planning Analytics objects between development and production environments. ## Before you begin Before transferring databases or objects, it is worth establishing a simple folder structure to organise migrations. We recommend creating a **Migration** folder within each database directory, containing separate **IN** and **OUT** folders. ``` │ ├── DATA ├── MIGRATION │ ├── IN │ └── OUT └── BACKUP ``` Within the **IN** and **OUT** folders, create a new folder for each migration using a consistent naming convention, for example: ``` 250629-MonthEndRefresh ``` Using dated folders makes it much easier to track previous migrations and roll back changes if required. When refreshing a development environment, it is also good practice to copy any ongoing development work into an **INPROGRESS** folder before replacing the database. This prevents unfinished work from being overwritten. ## ## Moving a production database into development Refreshing your development environment ensures developers are working with current production data while preserving any development objects that are still in progress. The process can be summarised as follows: ### 1. Prepare the production environment Before taking a copy of the production database: - ensure all users have logged off - run the **SAVEDATAALL** command to commit all changes to disk - stop the production database Once the database has stopped, create a new folder within your **MIGRATION\OUT** directory and copy the complete database into it before compressing the files. You can then restart the production database and allow users back into the system. --- ### 2. Prepare the development environment Copy the compressed database into the **MIGRATION\IN** folder on the development server. Before restoring the database: - ask all development users to log off - back up any development-only Planning Analytics objects into an **INPROGRESS** folder - run **SAVEDATAALL** - stop the development database Rename the existing **DATA** folder so that you have a complete backup before extracting the new database. For example: ``` DATA ↓ DATA_250629 ``` --- ### 3. Restore the database Extract the production database into the new **DATA** folder. Once the restore has completed, copy the objects from your **INPROGRESS** folder back into the **DATA** folder, overwriting the restored versions where necessary. This ensures you have the latest production data while retaining any active development work. --- ### 4. Validate the environment Restart the development database and confirm that: - the latest production data is available - all development objects are present - reports and processes behave as expected If everything is working correctly, notify your development team that the environment is available again and archive or remove the old **DATA_250629** backup. If any issues are discovered, stop the database, delete the restored **DATA** folder and rename the backup folder back to **DATA** before investigating the problem. ## ## Moving Planning Analytics objects from development into production Once development work has been tested, the required Planning Analytics objects can be promoted into production. ### 1. Prepare the development environment Ask all users to log off and run **SAVEDATAALL** before stopping the development database. Create a new migration folder within **MIGRATION\OUT** and copy only the Planning Analytics objects that are ready for deployment. Restart the development database once the export has completed. --- ### 2. Prepare the production environment Copy the migration folder into the production server's **MIGRATION\IN** directory. Before importing the new objects: - ensure all production users have logged off - create a backup of the production **DATA** folder - run **SAVEDATAALL** This provides a rollback point if required. --- ### 3. Deploy the objects Copy the exported objects from the **MIGRATION\IN** folder into the production **DATA** folder, replacing the existing versions. Restart the production server and verify that the updated objects have been successfully deployed. Once validation has been completed, users can be allowed back into the production environment. If any problems occur, stop the database, restore the backed-up **DATA** folder and investigate before attempting the deployment again. ## ## Final thoughts Following a structured migration process makes it much easier to move databases and Planning Analytics objects between environments safely and consistently. Taking a few minutes to create backups, organise migration folders and validate changes after deployment can save hours of troubleshooting if something goes wrong. If you're looking to improve your Planning Analytics development processes or would like an independent review of your environment, [**get in touch with the Aramar team**.](https://www.aramar.co.uk/contact/) Our Planning Analytics specialists can help you implement best practices that make ongoing development, testing and deployments simpler, safer and more efficient.