In the concept of virtualization, a server is replaced by another which pretends to be just like the original. There's no new HP 3000 in emulation, for example. Just the idea of one. The essence of the HP 3000, its PA-RISC architecture, is replaced using the Charon product: software that mimics the HP hardware. Virtualization engines use software to eliminate hardware.
Some MPE migrations which have been underway for years look like they may be using up virtual man-months, so the IT group won't have to adopt a new application. The plan and lengthy project time eliminates the need to go live with changes.
In a virtual migration, the organization knows its intention. Get onto another environment with mission-critical apps. But the work never gets completed, something like a "forthcoming" novel that's expected but unfinished. Virtualized migrating can very well be the reason any 3000 project still has a 2017 target date.
"These days with the tools that are available," said Alan Yeo of ScreenJet, "no migration should take more than 12 months." He added that he believes that engaging a migration services company of any reasonable size would get most of of an organization's code running in test-mode in about six weeks.
There can be acceptible reasons for a migration project timeline of more than two years. They often involve changes in the migration itself. A few that come to mind that we've heard of include failures of chosen tools, organizations that downsize during a migration, and discoveries that changed the scope of the project.
There's always the possibility that a seemingly-simple set of programs feeds data to and extracts it from other applications in the organization. But today's set of available tools to extract and clean and transform and load data really makes data more flexible and fluid. If an organization doesn't have these ECTL tools, this is not easy, however. (At this moment we're thinking about MB Foster's UDA Central, and there are others as well.)
Nevertheless, there's also a possibility that IT managers hold existing software in such high regard that a replacement solution has unnecessary expectations attached to it. Yeo had heard of one lengthy migration where payroll and financials were on a long-term timeline.
"Payroll and financials?" he said. "Why is anyone, in this day, migrating payroll and financials? Go out and get something off the shelf, instead of rewriting your payroll and financials."
He makes a good point that might apply to long-standing migrations. The relative complexity of paying employees and tracking P&L on a general ledger is small, compared to things like process and discrete manufacturing systems. Yes, big ERP systems do include financials and payroll integrated into the suite. They don't have to be that integrated, since moving data back and forth has become easier.
Educational organizations have special demands on their budgets -- they often don't have much of one. Projects compete for resources at schools, and it's not like the schools can sell more classroom seats to generate more revenue. That kind of cash generation comes through taxation and elections, both of which can be lengthy processes themselves.
As we approach 2015, it looks like it will be the 13th year when a migration could still be underway in your community. What's unfinished up to now may be just a virtual migration -- the sort that is on the operations calendar but not scheduled with any urgency.
I work with writers who have novels underway, and some of those novels are only virtual books. I tell them that a far-off deadline does not help complete their work and take it out of the status of "forthcoming." Immediate deadlines which are stepping-stones to a genuine goal make up the backbone of creation.
"We're working on a migration" sounds a lot like "I'm working on a novel." These things are never finished, I tell my writers. They're only completed, because we can always devise something else that would make them more perfect.
Even though perfect is a classic IT ideal, even sharp managers have found themselves testing new software in production mode, and getting away with it. "I did this for over 20 years and only once or twice got in trouble," a manager named Milo Simpkins said on the 3000 newsgroup this month. "But it was never something I couldn't recover from quickly, with no one the wiser."