Networks

Ask something
Discussion Locked

Worst Migration

0 helpful
8 replies

by sremiger

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
I am doing it right now. I was brought in to build a new system based on a current system. There is 200 gig of data in the old system across 14 databases on 3 servers after the conversion, We will have it down to under 80 gigs in 1 database. No foreign keys, no documentation and no indexes exists in the old system. The migration is the worst i have ever worked on but the expectations here are even harder to deal with.

8 replies

by clark1

And here I thought our migration from NT 4.0 to 2003 and exchange 5.5 up to 2007 was bad LOL

by jamesrl

This is in fact 14 projects. And some may go smoothly, some may not.

I've never seen a consolidation work as planned.

Its almost impossible to correct expectations in mid stream, but learn the lesson for the next project.
Tell them upfront that without documentation, its difficult at best, and there will be some trial and error.

James

by rocky

Setting the expectation was a comment that is 'right on'. I worked as a poduct engineer and earlier as a technician in a research lab and later I went into sales and marketing.

Customers come back to me if they perceive that I have served them well.

If the customer has high expectations either because of preconceived notions or because I've over sold myself, then it is more challenging to meet those expectations; however, if I educate my customer and also "lower" their expectations, then it is easier for me to exceed those lower expectations and have a happy client.

Sometimes lowering expectations means getting the customer to see the mess they have for what it is and letting them know up front that they have a mess that will require herculian effort to repair.

Having a technical mind, I tend to not want to BS people and want to deal with facts but the reality often is that the customer doesn't see the severity as it truely is nor do they appreciate the complexity of the solutions.

You have to train your customer or your customer will train you - and the train will run you over.

Begin training your customer from the very first meeting.

Best of luck to you.

by dt2

I would think that, once you get everything properly indexed, performance would omprove dramatically.

by itpzmaj

I agree. Worst thing is customer with a little knowledge of IT. (Let's say, as a joke, 10% of necessery knowledge.) I have worst expirience with that kind of customers.

by kerry.millen

The condition of the "old system" may be a reflection of how this company handles all their technology issues.

by jc2it

Politics are a tough thing to beat, and this is why we call it the 8th level of the network model.

The reason that there are so many disparate systems could very well be due to the lack of communication and teamwork between departments and middle managers. Does upper management support the move, or is it being pushed through by a lower entity?

I would be very careful about finding out the politics involved with each database as I am integrating them. What is the history of the data and why was each database developed?

Also, never knock the effort of others before you, even when you know they did something backwards. I would limit my comments to, "Well 10 years ago this was a good way to solve these problems.", or don't comment at all on the effectiveness and efficiency of the old system. They already know there is something wrong with it.

Finally, remember your knowledgebase and toolset is at least 100 times better than what was available only 3 or 4 years ago.

BTW, Good Luck! You will need it!

by ibwold

I've recently just finished a migration, albeit, not nearly as large, but similiar in tasks.

A few things I learned:

- Script the conversion if possible. This allows you to easily test the conversion process even if the source data (ie: original database(s)) changes.
- Verify data integrity. Address invalid/incomplete data, either inside the old system or during the conversion
- Identify and address all data conversions (ie: free text fields that need to be coded values, date field issues, etc)
- Make it a visual process. UML diagrams or even hand sketches can help clearly communicate complex processes between team members.
- Have a clear idea of how to verify the conversion (record count, amount totals, etc.)

In terms of client expectations... under-promise and over-deliver. Be able to clearly explain what you're doing and why.

Good luck!

This discussion is closed to new replies.