Over the last few months we've spent a lot of blog time talking about the how, why and what to move configuration data from one environment to another in Kronos WFC. There needs to be more conversation about the WHEN to do it.
I had a meeting last week about Change Control for Kronos. They have a large number of configuration and other changes that are ready to be promoted to Prod sometime soon. One of the tough parts of the promotion decision is when to move the data. It's obvious there needs to be a maintenance window, but what if the changes won't propagate in that time. We might need to stage the updates.
Sometimes changes can be moved any time. Other changes need to be promoted together and some are dependent on other changes being there ahead of them. Some changes can take days to promote and others minutes. In the Change Promotion document you built in Excel (ok), Google Docs or DabbleDB (better) or Sharepoint, there should be a column for dependencies and one for when in the process it needs to be moved. And perhaps one showing when it CAN be moved.
Scheduling some changes weeks before a major migration or update can be a real help, saving downtime and simplifying the overall effort; but one must be certain that those changes don't affect anything else. I always suggest that this Promotion document be tested in the move from DEV to TEST and then to QA if you have it. That way any kinks in your expectations of the affect the change will have can be verified.
How do you manage the WHEN of Change?
Comments