cancel
Showing results for 
Search instead for 
Did you mean: 

What is the best migration path?

Former Member
0 Kudos

Currently we have BODS 4.0 sharing BO CMS. We would like to setup new server with BODS 4.2 latest SP with its own CMS (IPS). Before moving all the jobs to new server, we would like to identify some jobs in older version, migrate them to newer version and test it.

New servers setup like DEV/QA/PROD.

1. Create a new repository in BODS 4.0 , move the jobs to be tested.

2.  Upgrade the new repository using repository manager from new BODS 4.2.

3. Test the jobs.

And also instead of moving all the jobs at a time to production, we would like to take approach moving some jobs at a time. Until all the jobs moved to new server, we would like to run both environments parallely. What iare the best practices to achieve this?

Or once we test some jobs in the new environment, upgrade the central repository and main repository where all the jobs exists. So migration will be complete at a time, instead of moving jobs in batches.

What do you recommend?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

This is what I have done in the past that has worked well. This assumes both your 4.0 and 4.2 environment are up and running at the same time.

1. In 4.0 system, create a new blank repository

2. Export existing job(s) from 4.0 into the new repository

3. Detach the 4.0 repository from your 4.0 system CMS

4. On 4.2 system, use repository manager to upgrade the repository.

5. Connect the upgraded repository in the 4.2 CMS

I prefer this approach because it leaves both environments intact in case any issues arise during testing, and then I can easily run the same job in both versions (using the same sources and targets) and compare results.

Former Member
0 Kudos

So when ever we want to migrate the jobs, we need to create new blank repository and move the jobs to new repository and migrate. I guess this is the only way, unless we want to migrate all the jobs at a time.

Am i corect?

DayaJha
Active Contributor
0 Kudos

Hi Jawahar,


Other Option is Move all Jobs in Secure Central Repository 4.0 and then Upgrade it to 4.2 Secure Central Repository, Then Create new Local Repository 4.2 & Import all Jobs from 4.2 Secure Central Repository.

Thanks,

Daya

Former Member
0 Kudos

Daya,

Thanks. But we don't want me to migrate all the jobs at the same time. We want to run both the environments parallely, migrate the jobs in batches.

DayaJha
Active Contributor
0 Kudos

Hi Jawahar,

Then in that case below scenario is helpful.

Scenario:

  • Create New Secure Central Repository 4.0
  • Move all Jobs in New Secure Central Repository 4.0
  • Migrate New Secure Central Repository 4.2
  • Create New Blank Local repository 4.2 & Move One Job at a Time & Complete Parallel Run with Old Environment.

Note:In that Scenario you must have 2 environment in place to complete parallel run.

Thanks,

Daya

Former Member
0 Kudos

Thanks Daya. Your approach will eliminate creating multiple local repositories whenever we need to move the jobs.

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

I think what ever you said is a correct way. Whether you use a atl or work bench is an option.

Arun

Former Member
0 Kudos

ATL is not an option here, since we migrating from 4.0 to 4.2. I read in this forum mentioning, ATL is not a recommended approach while upgrading. Always upgrade the repository.