The impossible deadline

JamesBowen

19+ years progress programming and still learning.
I've been given a new project which involves buying our major competitor.

  1. So I have to migrate there MS SQL database into our OpenEdge database.
  2. Take control over there .NET forms website and then move it over WebSpeed.
  3. To be able to reproduce there existing hard-copy letters and automated emails.
  4. Plus the possiblty of a truck load of other stuff that nobody else thought of.

    Where the hell do I start? Also did I mention that I need to do all of this by the end of January 2009.
So what I am asking for is what is the best approach to this project.
 
Looking for another job is a good one, but if you'd prefer to stay and take on the challenge...

How big is the database (number of tables and data)? How many programs, forms and letters etc are you talking about? How much money are you allowed to throw at it (and in a way, money means people)? How much support do you have for this "little project" within the organisation itself -- are you going to be hitting your head against a brick wall of people not wanting to help you do what you've been asked to do?

I would probably start with making a Progress/OpenEdge version of the database that preferably contains all, but at the very least a representative sample of the data in the SQL database (or are you allowed to invest in the dataserver for SQL so you can for now skip this step and convert the database at a later date??).

Then I would try to work out what the absolute bare minimum is that has to be ready so you have something to work towards - I know, if you ask the users they will tell you that it is all every bit as important, but there must be some core stuff in there, so find that. Then try to get approval to work on that first and make sure people (and management) are aware that they may not be able to get what they want or think they will get by end Jan 2009. Create a realistic planning based on work and availability of resources so you can show "the powers that be" what would be a more realistic delivery date *and* what you think they can get by the end of Jan 2009 and show that to management. Somehow you have to make people aware and believe in the fact that yes, you can do the job, but just not when they want it done.

For ther rest... some prayers may be in order - it's a good time of the year for that ;)

Good luck mate, sounds you will need it

Paul
 
OK, let me give a little more serious answer...

One of the big questions here is what kind of resources and experience you have. If you are one person and have only done small projects before, then seriously I think it is time to go to management and let them know that you aren't likely to make it. You really want to have an experienced project lead in there right away to even have the vaguest hope of making it.

If, on the other hand, you have enough experience to feel comfortable leading the effort, the very first thing I would do is to since down with something like MS Project or a similar tool and start estimating tasks and dependencies and resource allocations. It is likely to take you a few days, but it will be well worth while. For one thing it allows you to go to management real soon with an estimate of completion dates and resources required. They might not like the answers, but better for them to discover it now than three days before they expect to go live. Now you have an opportunity to adjust expectations or get more resources and consider options. Then, it will be too late.

Doing such a plan is going to be hard because it seems likely that there is a lot you don't know, but make your best guesses. Then, dive in and keep revising the plan based on what you accomplish and what you discover. If you run into some previously unknown issue in three weeks which adds three weeks to the schedule ... again, they aren't going to be happy, but you will have done everything you can to inform them about the issues and they will have participated in setting goals and providing resources based on that information. Likewise, this will help you keep them informed on whether you are ahead or behind of your initial schedule ... no surprises.
 
I've started at looking using Dataservers but I am not sure how well it will work running on Linux accessing ODBC drivers on Windows.

I've spoken to Progress NZ/AU and they want mega bucks just to have just to give me some training. Oh well.
 
Are you bound to using Linux? If not you can always have your DataServer run on a Windows box and have the rest of your app access that from your trusted Linux. To be honest though, I do not know how a DataServer will perform as the last (and only) time I used one was a couple years back with Oracle (and it was a desaster and soon replaced by a Progress only setup).

Paul
PS Whereabouts in Oz or NZ are you?
 
While I obviously know almost nothing about the two applications, my first instinct would not be for the Dataserver. A Dataserver can be a great tool for a long term bridge, but here I understand that you want to move everything to the same application, so anything you did with the DataServer would be temporary. That's going to be expensive and probably won't work that well anyway because of semantic mismatches between the two datastructures. Far better, I think, to focus on resolving the sematic relationship and then transfer the data into the new structure.
 
Are you bound to using Linux? If not you can always have your DataServer run on a Windows box and have the rest of your app access that from your trusted Linux. To be honest though, I do not know how a DataServer will perform as the last (and only) time I used one was a couple years back with Oracle (and it was a desaster and soon replaced by a Progress only setup).

Paul
PS Whereabouts in Oz or NZ are you?

I am not tied down to just using Linux. I think what I will do is install a new server (Windows) nothing to flash on the same network as the MS SQL Server Database and install the DataServer on that.

I am Working in Wellington NZ.
 
While I obviously know almost nothing about the two applications, my first instinct would not be for the Dataserver. A Dataserver can be a great tool for a long term bridge, but here I understand that you want to move everything to the same application, so anything you did with the DataServer would be temporary. That's going to be expensive and probably won't work that well anyway because of semantic mismatches between the two datastructures. Far better, I think, to focus on resolving the sematic relationship and then transfer the data into the new structure.

I've spoken to my Progress Account manager and I was tolled that could rent the DataServer product for the short time i.e. 3-6 months with support/maintenance which will be cheaper than buying the whole cow.
 
There's an old saying that has to do with renting ... but let's not go there.

My point really is that while that might give you easy access to the data and thus might allow you to write ABL programs to transfer, merge, process, and fiddle with the data ... which certainly could be a help ... that the key issue with two different applications, even if they use the same technology, is the semantic disconnect about what information they contain and how they organize it. You're going to have to work out that mapping regardless.

To move the data from one to the other, you really have four choices:
1. Write code on the other end to dump data in a form where it can be loaded into your system.
2. Dump data from the other end and massage the text files until they can be loaded.
3. Connect to the other database with the DataServer and use ABL code to transfer the data into your system.
4. Create an OpenEdge schema corresponding to the other system's schema and dump and load and then proceed as in #3.

Of these, #2 is a problem since I think data is intrinsically harder to manipulate as text.

#1 is probably not ideal unless you have people around with good skills in the other system since you would be trying to work in a presumably unfamiliar technology. On the other hand, it is only SQL, after all.

#3 and #4 seem to me fairly equivalent. #3 means you have to acquire and learn about a technology which you are then going to throw away while #4 requires some work to build the schema.

The degree of semantic mismatch will be the key in determining how difficult this part of the overall task is. I've done some conversions which were pretty easy because the old system was data poor compared to my system. But, I also worked on one where the company was trying to move from my system to another one where they eventually abandoned the product and stuck with me because there was such a bad mismatch and they would lose so much data.
 
Back
Top