February 7, 2007

Migration Instructions

Today's post continues the overview of PeopleSoft environment usage and migrations. I probably have another week or so to go on this topic and then will finally wrap it up. (Promise!) But before getting into today's item...I just noticed that it's been three years now since I starting writing these weekly rants and ramblings. Some readers have sent good comments and even compliments, and these are much appreciated. Part of the reason for starting this series was selfish—I wanted to build a sort of library of information and opinion that I could pull from when clients asked common questions, and that has happened. But I hope these have occasionally been useful to you as well.

In last week's discussion of three-step vs. four-(or more)-step migration paths, I mentioned the role of a separate production control group (or DBAs, or whoever handles UAT and production migrations). This is a common setup. In many cases, this separate group works with systems other than PeopleSoft. Direction needs to be given. There is probably a form to fill out. Here is where you can have a process that helps to ensure accurate, smooth migrations, or a process that practically guarantees problems.

First, why do we need a separate production control group at all? The previous post gave one common reason: The need to protect "real" data. There are others. But one reason commonly given is that this separate group acts as "another set of eyes" to check development and/or migrations. This is a good idea in theory, but it works only if the production control people actually know what PeopleSoft development is all about. In many cases they don't or can't, especially when they handle multiple systems. Even when they are experienced developers, do they really review objects, or do they just mechanically follow the steps?

In any case, as I said, there is probably a form to fill out. The less experienced production control groups will probably demand a highly detailed document. This will list the steps to be followed, but it might also include lists of objects and what to do with each. It could even require screen shots of steps to be taken. Or, taken to an extreme, it could require code listings and screen shots of objects.

Now, documentation is (usually) good. But remember that every time one document or object is translated into another document or object, errors can be introduced. For example, Application Designer projects contain (most of) the objects to be migrated and/or deleted. If this list must then be transferred to a separate document and these two sources must then be kept in sync, there will be errors at some point for obvious reasons.

More documentation is not always better. Sometimes having more documentation introduces more risk. The trick is to determine what types of documentation will be useful. If the production control group must be led step-by-step through normal migrations, is any real value being provided? Might it be better to move this function back into the PeopleSoft development group, possibly assigned to one or two senior developers or managers? Even if the responsibility is not transferred, I would suggest that you encourage the production control people to use the tools available (such as App Designer or Stat). They should also be aware of your standard procedures and require specific directions only when there are deviations from those standards. For example, if you normally do not migrate menus, then everyone should know this. The production control group should not migrate menus unless given specific instructions to do so. It should not be necessary to state "remember not to migrate the menu" in the migration document. The production control group should know what it means to "migrate a project" and should be able to perform this for normal projects without detailed instructions.

Another example of a standard concerns whether the developer or the migrator is responsible for setting the "upgrade" flags. Is the migrator expected to run the compare report to set the flags, or does the migrator simply use the flags as they exist? Or is the migrator expected to rerun the compare and then report back on any inconsistencies with the way the flags were previously set? Work this out in advance.

Of course, there are always special instructions for certain projects. If your environment is informal enough and your processes smooth enough to support this, you can just put these instructions in the comments box of the project itself. That's close to the source and will be helpful to other developers who look at your project later.

Until next time...