Migrations - What can go wrong

Posted by: Brent Martin in PeopleTools

Tagged in: Untagged 

Brent Martin

Don't you hate it when you ask for a project to get migrated to Test, and it doesn't work there?  Then you do some research, and it's missing some critical PeopleCode or SQL and the users are getting big ugly errors and questioning the quality of your work.  Okay, maybe it's not always that dramatic, but it is always frustrating.

Here's some of the reasons things don't always get migrated and what you can do:  

 

 

  1. It’s not in the project. Just because you insert the App Engine doesn’t mean you inserted the App Engine sections. Just because you inserted a record definitition doesn’t mean the SQL/Record PeopleCode got inserted. Just because you inserted a page doesn’t mean the Page Pcode got inserted, and just because you inserted a component doesn’t mean the (almost useless) menu that refers to it got inserted, or the pages it refers to, or the component PeopleCode got inserted. Review the “Upgrade Tab” of your project to make sure all of the components are really in your project before you request that migration!  Or better yet -- use the F7 key to insert everything you touch into your project as you work.

  2. The upgrade flags weren’t set right. Once again, check the upgrade tab. Make sure the “Upgrade” flag is set for EVERYTHING that you want to migrate. Also, make sure the Action is set to Copy.

  3. The object is locked in the target environment. This usually happens in special circumstances (like migrating code back to the development environment when applying patches). I guess it COULD happen if you have change control turned on in your target environment, but I can't think of a reason why you'd do that.

  4. It did get migrated, but you don’t have security to see it. Lots of times the security that worked great for you in development won’t work in other environments because frankly nobody uses the ALLPAGES permission list except in DV. Part of the migration request should be a note to your security administrator to set it up in security after the migration.

  5. The person migrating made a mistake. This happens less than you might think. The actual migration process is pretty much a no-brainer. But mistakes can happen and the person migrating might accidentally unselect an object type, or migrate it to the wrong environment. Usually it’s easy to open the project in the target environment to make sure it exists, then double-click on whatever object you want to check to make sure it’s there. You can do this even if you have read-only app designer access.


That's all I can think of.  Did I miss anything?
Trackback(0)
Comments (7)Add Comment
0
Project validation
written by Chris Heller, October 24, 2007
One thing worth doing is running Project Validation on the source database, and then run it again on the target database after the migration. That won't catch all errors, but it will catch a lot of them.
0
...
written by Ramesh, October 25, 2007
You can probably enable the option 'Insert Object when Modfified and Saved' which under Tools-> Options so that you would not forget to include an object.
Make sure that Done falg is unchecked in the upgrade tab for the objects you want to migrate.
0
Expectation setting
written by George Sabini, October 28, 2007
Certainly we all want to be efficient and have migrations work on the first shot and finding ways to improve migration success rates are valuable.

But recall that a test environment isn't only to test the code itself, but it's also meant to test everything around operationalizing the code. That includes testing the migration. DEV->TST migration failures are acceptable. TST->QA and certainly QA->PRD migrations are not. Sounds like your project might want to set the expectations of the testers that they're actually testing the migrations as well as the code. Of course, that's not sometimes possible due to team dynamics. The time of the testers might be more valuable than the developer's / administrator's time or there might be perception concerns. Then certainly the last step of the migration should be a validation by the developer / migration requestor to confirm that the migration occured completely and correctly.
0
...
written by Matt, November 05, 2007
As a follow up question. Has anyone seen issues when migrating an AE program while that same program is running in a target environment?
Brent Martin
RE: Migrating AE while program is running
written by Brent Martin, December 26, 2007
I've never tried it, Matt. I could see how it might cause caching problems or make the running program behave strangely. It's always a good idea to do migrations during a quiet time on the system when there are no scheduled batch jobs and users aren't normally working.
0
Modified People Code not getting migrated from DEV to TEST instance
written by Sumit Kedia, October 22, 2008
Hi all,
I have a problem in migrating the people code from DEV to TEST. All the objects are getting migrated there, but the people code that i have changed fro them in the DEV is not getting reflected in the TEST.
I took the record, edited the people code, added to a project..build it...copied it to a File.
In the TEST, i copied the project From File. All the objects are gettng reflected here except fro the modified peoplecode.
PS. the Upgrade tab thning which has been explained above has been tried but with no result.
Brent Martin
RE: Modified People Code not getting migrated from DEV to TEST
written by Brent Martin, October 23, 2008
I wonder if you can migrate any peoplecode, or if it's just this one record. I don't have any great wisdom on this, just a couple of obvious things:

1) Make sure when you click the upgrade tab on the project, that you see Record PeopleCode as part of the project, and when you double-click on it and review the upgrade flags that it's all set to upgrade. Sometimes if you've run a compare report, the upgrade flags will be unchecked.

2) Make sure that you're not using change control locking in the target environment, and the record is not locked.

3) Use Configuration Manager to purge the cache of the migrating workstation before you attempt the migration.

Write comment

security code
Write the displayed characters


busy