How to Move a Database Between Environments in IBM Planning Analytics #

Moving a 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.

<Database Name>
│
├── 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. Our Planning Analytics specialists can help you implement best practices that make ongoing development, testing and deployments simpler, safer and more efficient.