I revisited a set of user conference slides from 2004 recently, and I found a scheduling milestone. A presentation at that final Interex show in Chicago included a schedule warning. In that year, it was about halfway through the period HP gave the community to get away from their HP 3000s. The deadline for the end of HP support was December 31, 2006, as of the week the presentation rolled out in Chicago.
"Put your plan into the budget during this summer of 2004," one slide suggested. Using that timeline, an IT manager could commence migrating by the summer of '05 and complete a migration by the end of 2006. To be sure, 18 months is a swift migration schedule, but it's possible -- if a company can budget for some outside expertise for project management and coding. The tests will usually be handled in-house. That's up to one third of a migration project's timeline, according to migration services experts like MB Foster.
By the next fall, HP was pulling the carpet out from under such companies. That deadline for HP support got extended by 24 months. With that change, that halfway-gone point was still at the moment of HP's rescheduling. But now there were more than 36 months left. People had not migrated in enough numbers. A greater factor: HP made a business decision to keep support business alive and earning revenues for another two years. It was high-profit revenue. High enough that the deadline got moved again, out by another 24 months.
Since those days, we've seen many customers use the same sort of rolling-forward deadline for their migrations. They plan for the end of 2013, for example, then push out to the end of 2015. Just like HP, customers in places like California school districts and manufacturers in the Southwest are taking more time because they like the return on investment. They can afford to reset the halfway mark.
But what if 2004 was the start of 95 percent of migrations, and the decade since then represents halfway-gone? What's left by now in the user community still includes companies of serious size.
Another customer, the San Bernadino, California school district, will not switch off until the end of 2017. So far away that its resident 3000 guru will already be retired. In that shop, even the exit of expertise won't move things along faster. Operations calendars play a role in scheduling.
The end of the calendar year is a typical time to switch things over for the schools that use the 3000. Classes end in December for a long break. E-commerce and retail companies like Musician's Friend, a former Ecometry site, consider the middle of summer to be their safe cutover time.
A one-month operations break, or even the 90 days before holiday retail time, is a short window compared to a full year. If a site doesn't get to its deadline window in time, there's an extra 6-12 months of 3000 operations to schedule. This mandates a Sustain plan.
Even back in 2004 the presentation advice included Sustain strategy. It included the same counsel given to migrators: Innovate before you migrate. Innovation is the one advantage of extending a halfway point. The IT staff can do some immediate-payback work. Innovation to existing systems helps as soon as it's tested.
Innovations in existing 3000 systems is not as crazy as it sounds. If you're aiming at innovation targets, these three were part of the 2004 slide set.
- Projects that affect operational efficiency and ROI
- Projects that build sills and experience on your staff
- Projects that will help with year-over-year comparisons in the future
If that final target isn't clear, it's a good practice to get another set of eyes on migration planning. IT stakeholders are one set of eyes. Another potential is the migration planners in your community. Knowing what to innovate before you go away: this is also preparing for a migration.