Re: Informix to Oracle migration

On Fri, 27 Feb 2004 07:43:55 -0500, Mark C. Stock wrote:

DO check out the Aubit4GL project. The latest release is working for most code with enough coverage that there is at least one large 4GL customer using it for production already. Automagic data and SQL dialect conversion included.

The version on source forge is older but the Aubit site has the latest.

Art S. Kagel

> "Captain Pedantic" <theharlequin36_at_hotmail.com> wrote in message
> news:c1nda4$1k5p2g$1_at_ID-162943.news.uni-berlin.de... | A potential customer
> has asked me to provide an estimate of how long it will | take to migrate
> their 4GL suite running on Informix "to Oracle". | | (I'm reminded here of
> Obnoxio's post of a while ago ridiculing another | rather vague question: "I
> have a piece of string in my pocket. How long is | it? It's red by the way
> ...")
> |
> | Seriously, though, what sort of things should we be asking beyond these?:
> |
> | 1. Complexity of schema (what sort of things, other than serial, are going
> | to be difficult to convert?)
> | 2. Number of lines of 4GL
> | 3. Number of stored procedures and triggers | 4. Total number of tables |
> 5 Volume of data
> | 6. Availability of original programmers/BAs | 7. Quality of documentation
> |
> | Assuming they don't want to re-write their app, they have to use a |
> third-party "universal" compiler like 4Js or Querix (or of course Websphere
> | EGL, if they've the time to kill). Any other options? | | All
> (constructive) comments gratefully received. | | thank you.
> | Capt. P
> |
> |
>
> target platform?
> essential business functionality? -- most 'migrations' need to fix badly
> implemented logic
> quality of original design? -- how many kludges in the code? quality of
> data? -- how much cleaning will be required to move it to a normalized
> schema
> how old is the app and what has happened to the business since then? what
> are users currently doing with the app? what are they doing to work-around
> its limitations? what goals were never met with the original app that could
> be achieved with the 'migration'?
> what type of cutover period is anticipated? how will it be managed?
>
> i really don't believe in 'migrating' an application without good analysis
> of the current state (health, usability, correctness) of the application and
> data, and then coming up with a strategy for balancing redesign, repair, and
> redeployment -- usually the same (or perhaps less) expense that is involved
> in attempting a technology migration will provide a more correct application
>
> if possible, first give them an estimate for 'getting the string out of
> their pocket'
>
> ;-{ mcs
Received on Fri Feb 27 2004 - 13:03:21 CST