Some time ago, we were tasked with a project to come in and replace a customer's old Mainframe system with a new intranet ASP.NET solution using SQL Server as the back end. Part of this was a re-engineering of the business as well - essentially, as we change the system, we were to be thinking of how we can better do business.

So, the first task was to come in and do the logical and then physical data models. The customer was in on these dicussions and had complete sign off. The next phase was to actually do the design and building of each module. Well, to make a long story short, the programming has been done and we are now into parallel testing of the system. Things are going wonderful for most of the modules so far - Except One.

We have one system where - if you would only let the business users see the application and reports, all would be well. It works with the new integrated workflow and automates previously manual processes and performs great per the specifications. Parallel testing has uncovered a few issues though with the migrated legacy data. The builders of the legacy system are having a very hard time understanding the new schema and business process, therefore, they are having a very hard time understanding how to take the legacy data and put it into the new schema. Because of this, they are calling meetings of the business users and stakeholders and telling them that the new system doesn't provide data that the old system did (when it really does) - this does make the new system look bad.

This is frustrating, to say the least. The new system works great, and provides everything they need and wanted, and if not for the inability of the IT staff to fill in the new tables with the old data, the business users would be happy with the new features and functionality.

I'm asking for suggestions for how to handle this. Because of some political moves, the new "architect" has no idea of how the system works, and cannot fully understand the ramifications of the changes the IT staff is requesting. The IT staff wants some fundamental changes to the system, which are essentially un-necessary and actually are a bad design - but they ARE the customer.

Any thoughts?

  • 1
    in addition to the great responses below, you should ask the opposers to provide you with an example of data that they think isn't supported. Then convert the data to show them (and the decision-makers) that they're wrong. Commented Mar 5, 2012 at 22:14

6 Answers 6


Your team needs to do the data conversion for them. You really should have done it for them in the first place.

I've been involved in a number of expensive platform migrations and the vendor always, always has their own data conversion team who are responsible for understanding the legacy system, writing all the migration scripts, doing all the tests, and generally making sure that everything does what it's supposed to.

Some companies may have brilliant IT staff who can do it themselves. Others may claim to be able to do it themselves, but actually can't. In the latter case, you need to be humble enough to sit back, but also be prepared to step up if and when the management has decided that the internal team isn't doing a good enough job.

This is your system and your implementation. You and you alone are responsible for making sure that it succeeds. Do not expect the customer to be able to do any part of this themselves. Only if they absolutely insist on doing this part themselves should you even consider that option, and in that event, you need to cover your butts - there should be something in the contract saying that if they choose to do this themselves, then they are responsible for its outcome.

They can pay you to babysit their team if they want, and they can pay you to start all over if they want, but don't waste unnecessary cycles without some kind of agreement in place. Especially if you're on a time-limited or fixed-cost contract, this situation is death.

The point is, as you say, they are the customer, which means that they do not work for you. In fact, if you're a cynic like me, you might suspect that some of them are actively working against you to hold onto their job security. Relying on the customer to do any part of your implementation is a mistake.

If you have to hire a couple of minimum-wage data entry slaves to do the data conversion manually - do it. Anything to put the outcome back in your hands.

  • 4
    "you might suspect that some of them are actively working against you to hold onto their job security" +1, I have seen this before TOO often.
    – maple_shaft
    Commented Jul 28, 2011 at 15:22
  • 5
    +1 "You really should have done it for them in the first place" The most you can ask the legacy team to do is export their data in a form you can capture, restructuring the data is your responsibility. Unfortunately the bottom line is it's up to you to get that data into your system. Best of luck mate. Commented Jul 28, 2011 at 15:35
  • @Aaronaught - we have had some discussions internally about that very thing ("should have" done it ourselves) - of course, hindsight is always 20/20. Thanks for the reply (as well as everyone else who replied). This is definitely a lesson learned.
    – Catchops
    Commented Jul 28, 2011 at 20:29
  • @Catchops: I apologize for what may have sounded accusatory; of course it's easy to speak from hindsight and it's a mistake that any new team might make, especially since clients have a tendency to make light of the work and assume that it should be a lot easier than it is. All I meant to convey was that moving ahead without such a team/process in place is generally a mistake, and one that likely needs to be corrected.
    – Aaronaught
    Commented Jul 28, 2011 at 21:50
  • @Catchops: This is the only real answer. Just contact their team, get a physical dump of the data and do the conversion yourself. You might even put a guy or two onsite to do it.
    – NotMe
    Commented Sep 26, 2011 at 2:34

They are the ones paying the bills so in the end you have to give them what they are asking for even though it wouldn't be the best solution and a step backwards.

You have to consider however that perhaps the people who used to use the mainframe have a point. My wife used to work for a bank where she used some mainframe system to enter various financial transactions using hundreds of different types of codes. It was essentially its own mini-language. When the bank spent millions of dollars implementing a GUI based system that greatly reduced complexity and the steps involved, they found later that productivity PLUMMETED and never went back up.

The fact of the matter was that while the mainframe system was unnecessarily complicated and had a high learning curve, they were MUCH faster with it than the GUI system because they became adept at entering hundreds of transactions an hour simply by typing fast on a keyboard. It led to a mass rejection by the user base and the project was scrapped as a complete failure. Productivity returned.

The moral is, don't completely dismiss the customers concerns. Take their considerations seriously and ask yourself if the solution you are providing meets the needs of ALL the stakeholders.


them that the new system doesn't provide data that the old system did (when it really does).

You should take this VERY Seriously..


1) Assure management you are working with the Legacy guys to get all of there concerns resolved.

2)Be sure you fully understand what they are saying is missing and why it is needed. Work with the legacy guys to insure this. Then RESTATE The issue, and have them say "Yes, That is our concern."

If you agree with there concerns then:

3) Then propose a solution, get the legacy teams input\validation on\of the solution.

4) Proceed with corrective measures.

If you fully disagree with the Legacy guys, and believe they are concerns are not valid then :

3) Express there concerns to management using that same language that the Legacy Guys said was correct. And have Management decide where or not you should be concerned with it.

"The legacy Guys are afraid that XXX, I'm not sure its an issue because of YYY. Are they correct in there concern?"


I suggest a big - panic smothering email, hit everyone associated not just their management. Keep it short and to the point.
2 points:

1) We can address your concerns at a meeting/phone call (propose a time)

2) We have complete confidence in the system as it is without the hassle and expense of additional changes

It sounds like you have a list of their concerns and you can go down them point by point in the meeting. You just need to stop the panic, let them cool down a little, and then hit them with truth. Even offer to come in and help with the mapping of old data to new. If they still demand changes... well it's their money.


First, I want to point out that while the IT section may be your interface, the real customer IS NOT the IT section, but the business for which the IT section works. Doing something to hurt the business to appease IT would not be good service.

Sit down with IT, informally. Buy them donuts. Take the role of student to their teacher, and ask "What is wrong with our software design?" Listen to both what they are saying and what they are not saying. They might have a point that has been overlooked in the original specifications or have concerns based on past issues. Then again, they might be reacting due to fear of something new. But, the point is, if you know their objections intimately, you are in a better position to effect a positive outcome and answer their objections.

You had mentioned that the problem was in data migration from the legacy system to the new system. If the IT section is having a problem migrating the data over, I would consider building them a small tool to do so quickly and cleanly.


Consult with the IT staff of your customer to support the migration of the old data to the new system. Someone from your firm who understands the new data format should physically just go there and help the IT guys do the migration.

That way hopefully they can teach the IT guys about the new system, the data gets migrated correctly, and your implementation goes more smoothly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.