Hi All,
We are planning to Migrate from Windows V7.5 to Windows V9.1 and would appreciate any help with this process and estimation
Landscape:
5 Projects
1000+ jobs
200+ Routines
100+ Batch jobs for Control Flow (No Sequence Stages used)
10+ Universe Basic Program called from Datastage
Jobs mainly use these stages:
FTP, Transformer, Aggregator, Seq File, Unidata stages
Src/Tgt
SQL Server, SAP (via ODBC), Unidata, Files, Hash Files
My questions are:
1. Will we be able to port these Routines directly to the new version or these need to be re-written?
2. Will we be able to port the Universe Basic programs to the new version or these need to be re-written?
3. is Unidata Stage still supported in V9.1?
4. Is Batch job based control mechanism supported in V9.1 or we will have to redesign using Sequence jobs and stages?
5. Migrating jobs to new version - unless we have stages that are not supported in V9.1, is this relatively as straight forward as Export and Import of the projects and then Recompiling the jobs?
6. v9.1 is supported in a Virtual Environment
7. Any rough guideline on the time we are looking at this Migration project
(excluding Testing which I understand will be a major factor)
Thanks,
VN
Migration from 7.5 to 9.1
Moderators: chulett, rschirm, roy
Some quick answers...
1. They will import directly and should not have to change.
2. See #1.
3. I don't recall it being deprecated, would be shocked if it is any kind of gone.
4. See #1.
5. It's as straight forward as that.
6. Yes. Was going to write up something more comprehensive but let's just leave it at 'yes'.
7. No clue there... as you've noted, testing will be the VAST majority of the effort to identify any areas where functionality has changed.
It sounds like you may be an all Server shop, seems to me if that is true it would cut down on the amount of loopholes that were closed in the product you may be relying on. Meaning your testing time wouldn't be as bad as when there are Parallel jobs involved... especially Parallel jobs in early versions of the product.
1. They will import directly and should not have to change.
2. See #1.
3. I don't recall it being deprecated, would be shocked if it is any kind of gone.
4. See #1.
5. It's as straight forward as that.
6. Yes. Was going to write up something more comprehensive but let's just leave it at 'yes'.
7. No clue there... as you've noted, testing will be the VAST majority of the effort to identify any areas where functionality has changed.
It sounds like you may be an all Server shop, seems to me if that is true it would cut down on the amount of loopholes that were closed in the product you may be relying on. Meaning your testing time wouldn't be as bad as when there are Parallel jobs involved... especially Parallel jobs in early versions of the product.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
leaping from 7.5 to 9.1 will introduce stricter metadata handling rules. Be prepared for compile errors and runtime errors associated with column type mismatches.
you can port over code as is, but enhancing them to use new features within 9.1 will benefit you in the long run.
Depending on volume of data, you may wish to transition server jobs into parallel canvas. Often times that process is deemed "out of scope" for the migration process. So it never happens. Then when metrics are gathered to see the net gain for having spent so much money on the upgrade project... you don't really present an acurate picture.
you can port over code as is, but enhancing them to use new features within 9.1 will benefit you in the long run.
Depending on volume of data, you may wish to transition server jobs into parallel canvas. Often times that process is deemed "out of scope" for the migration process. So it never happens. Then when metrics are gathered to see the net gain for having spent so much money on the upgrade project... you don't really present an acurate picture.