Taking Care of Too-Great Expectations
October 26, 2012
Apple is weathering the woes today of an entity which is managing expectations that are too great. Migrators may be laboring under the expectations of moving too much of an HP 3000 to another platform at one time.
Of course, these are very different times for these subjects. Apple set a record for a single quarter. At $35.9 billion in sales ending Sept 30 -- a boost of 27 percent over last year -- it's on a run rate that can make it a $143 billion company during 2013. People continue to call Apple a consumer company, although millions of its devices are powering the mobile needs of business. You simply cannot sell 40,000 phones and tablets -- a whopping $24 million worth -- in a brief 90 days just on the whims of consumers.
So Apple's on a mobile computing upswing, but not enough for the finance analysts. These experts who predict how much a company will earn guessed a little more than Apple posted. So today's a down day for the stock, just at $593, the first time under $600 since last August. HP used to suffer from such Great Expectations. Today, not so great.
However, the HP 3000 has expectations as well. Not for the growth of the platform or an increase in the revenues from its economy. 3000 expectations run to how much of its databases and applications need to be mined and moved -- and how much can remain on a 3000 in near-line storage, ready for the ultimate extraction.
Foster noted during the webinar that some customers are even purchasing 3000s for the specific reason of putting data onto the equivalent of a railyard siding. Of course, that's a a low-speed track section distinct from a running line or through route such as a main line or branch line or spur. But the sidings might still connect to higher speed sections.
"Among the things we've discovered is that when you go to extract your data, obviously you're reading a lot of data," Foster said. "That has an impact on the amount of CPU cycles and bandwidth being used to help data across to the other machine. You have to make sure you understand the timing of when you do that. It wouldn't be a good idea to do that in the middle of the day." But then came the surprises in expectations: 3000s on some kind of new mission, as well as what you can expect to move.
For that extraction reason, some of our customers have gone and bought a separate 3000 to stage the data. They just move the database. They don't move any of the code. They take that database and use it as a staging area to work with it. On the final extraction, they'll go back to the production database. At least they've got a working area where they're not interfering with day-to-day production. You might be able to come up with a very low-cost HP 3000.
There was more to consider about too-great expectations of migration of data.
Some of our customers have been able to work with us to get a methodology that allows them to move just the last month's records, or the last week's records, at the time of moving between systems. That's because all the rest was already staged. History is just history. As long as you can prove that the totals of all of the above equals the total of what you've moved, there's not a problem. Except in cases where you've got revisionist history, the history shouldn't be changing. If you look at it, about 90 percent of your database of transactions didn't happen in the last week or month.
Using this method, a customer could do a first run of data extraction, make adjustments to the process (item names that might be reserved words, different transfers between datasets), and then take a larger segment of the database and repeat. If a migrator has great expectations of making a complete move of data in one pass, they're overlooking these adjustments.
"We've seen customers where it actually takes two days to move all the data, and it ran into some kind of problem," Foster said. "Then we had to check the logs for details." Naturally, UDA Central has a comprehensive logging capability.
A customer from the UK in the webinar, who's moving off a version of Ecometry to an app using SQL Server, said he'd need to check on his permissions to access that target database. It's also essential to be adjusting the expectations for the time to clean up and route these extractions correctly, Foster said. Then there's the understanding that not everything's got to be migrated.
"Customers don't think of all the issues that there might be during the initial stages," he said about more typical sites. The fact that the UK user was on the call showed some foresight. "It's not until they get deep into the project they realize there might be any problems."
You consider how much data you expect to keep, "not only from the accounting perspective, but also for marketing, merchandising and purchasing," he said. "We suggest people start a migration by looking at how much must happen, and do it early. If they discover during that look they need an extra six months, it's better than learning they don't have any time left at all. Know how long it will take from the beginning of the data dumping to the end."