Archives of the TeradataForum
Message Posted: Tue, 18 Dec 2001 @ 18:10:45 GMT
I've been involved (to a greater or lesser degree) in a couple and each one was very different. So I'm going to make some big assumptions and go from there.
(2) the application databasenames and usernames on the smaller system are not in use on the larger system (actually, usernames may not be an issue)
(3) final goal state is to end up with a "single version of the truth" (sorry, too many NCR presentations !) - implemented as a single LDM/PDM on the new system.
Initially, run the two applications side-by-side on the same physical platform using completely different databasenames (maybe usernames) and gradually combine them into a single set of physical tables. For tables such as common reference tables you can use a view for one application to point to the physical table(s) in the other.
- if your new system is 16-nodes the "smaller" one is probably small enough that you can migrate the data using a archive/copy approach and don't need to migrate the data gradually.
In this case test the data migration process at least once. One one project I worked on we ran the test twice, the third migration was the real one.
- for the 'smaller warehouse' batch work, you may want to consider initially using the same tdp/host names but simply change them to point to the new system. Again over time you can change the logon string to point to a common set of names.
If you're running work from MVS and currently the 'smaller warehouse' application uses a different TDP name from the new system you could even consider running a second TDP against the new system for a while. Whether this is better for you or not probablt depends exactly on your current setup.
- when you have two applications running on a single box you may find that there will start to be some political battles ahead. My advice is to spot these early on and raise them with 'management' (aka "light blue touch paper and stand well back" !)
I worked on one system merger where a second application was joining the first on the same system. Up to that point, the first application team had determined when the system would be available for maintenance, when backups would be taken etc etc. That was ok as they were the only application on the system.
With the addition of the second app. some of these decisions had to be moved to a central group - which caused a few organisational issues.
- book a nice long vacation starting the day after you go live, but don't let anyone else do so !
If you've any specific questions let me know.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|