Hours spent outside of migration
March 12, 2007
Monday morning dawned with a small smile on North American IT managers' faces. The "mini Y2K" of the new Daylight Saving Time deadline passed without incident. Unless you were a migration manager at an HP 3000 site, watching hours of productive time drip away in yet another unforeseen diversion.
The DST dance — first, we've got a bit of software for you to keep your time straight, then oh wait, it needs more work, so back out those changes — is all too typical of today's IT change calendars. These events suck up manpower and money, the resources that many average-sized 3000 sites try to reserve for migration projects. The smaller the shop, the harder they must work to set aside migration resource.
Even a homesteading 3000 customer must deal with a DST event, but at least that kind of shop has more modest computing plans. Rather than changing platforms, or applications plus a platform, those sites manage day-to-day challenges. The dirty little secret is that those day-to-day ops in IT now include plenty of governmental compliance work, satisfying auditors more than ever before. Some companies have calculated their bill for remaining a public company — and paying to make regulated, mandated changes — and decided that buying back their stock and going private is cheaper.
DST typifies the reason most migration projects are taking longer than estimated. As important as migration may be to a 3000 shop, there's no ticking time bomb in that project unless your application provider has gone belly up. In contrast, we see 2 AM on Sunday morning, or this coming September for customers running banks and encrypting data. Real deadlines, soon, and with easily measured consequences if you miss them.
On Friday afternoon I talked with a president of a company running HP 3000s, HP-UX, Linux and Windows workstations. A pretty common mix of systems for a 3000 user. This was not a massive shop, either. Fewer than 20 servers including blades, fewer than 100 workstations.
Their bill for DST? Four man-days, and a ticking clock of work that could only be started when Microsoft finally released the needed patches for DST at the beginning of the week. He said his lead engineer on the DST project had only left the shop at 8AM Friday morning, after working all week.
HP didn't do a lot better on its go-ahead-time for 3000 DST changes. MPE/iX customers got their needed patches about a week before this weekend's deadline.
There are some IT historians, especially in the 3000 community, who say that the Y2K event was the only thing that kept the 3000 migration march from starting sooner than late 2001. That viewpoint might be correct, but migration managers shouldn't take much comfort in having such a large system change out of the way. the path toward the future will be littered with things like DST changes, often instigated by governments and regulators. Every one of them will have to take a higher priority than migration — and will pull resources off migrations, too.
Adjust your migration calendars accordingly.