Making a Way Forward by Riding Data
March 24, 2015
Around midday tomorrow, up-to-date instruction about migration will be offered on a webinar. The presentation is not about the platform and app migration that has galvanized your community. It's even more important, because everybody will need to do this migration. The movement is as undeniable as the tides. Data's got to be moved, because things improve as they change.
It's employing something better and more efficient to handle data — that's what sparks this migration.
At 2 PM EST in the US (11 AM Pacific) MB Foster's showing off the means to migrate HP 3000 data. For about 45 minutes, an interactive Q&A deals with the strategy and processes to move databases, a trip that can lead to MS SQL, Oracle, PostgreSQL and other targets. UDA Central is the means, but the advice goes farther than a straightforward product walkthrough.
You can sign up at the MB Foster website. The meeting gives a manager the opportunity to gather with some like minds. One of the most rewarding parts of a these Wednesday Webinars, as the company calls them, has been getting on the line with other managers. User group meetings used to be the only way to hear about best practices from community members.
For example, answers to these questions will be up for consideration this afternoon:
- How many internal resources are directly involved on a daily basis to extract, transform, migrate and supply supporting data for your organization?
- How much time and effort goes into this process?
- How can you speed up data delivery, reduce the time, effort and internal cost related to data migration?
Data migration is always about transformation, whether the target is outside the MPE realm or not.
Foster notes 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 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 says. "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." And then, a surprise about expectations: 3000s on a kind of new mission, along with what you can expect to pack up and 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's 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 can 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.