My client believes that he just has to copy the data over into the new database using some kind of migration tool and change the app's database configuration file.

While I am sure there are some parts of the app that would still continue to work, I would that bet that there would be a significant number of SQL errors thrown by the new database.

I've tried to explain this but he insists that "SQL databases all the work same way". Unfortunately, we don't have time to prove this by setting up the new database and migrating the data over.

Furthermore, the client intends to do it himself, so I don't see why we should spend any developer time on it. All he is asking for is advice and support when he attempts it himself. How do I tell him tactfully that he will most likely fail?

  • What is the framework of the existing application - Java? .NET? Or PHP? Something else? Commented Dec 19, 2015 at 18:04
  • 2
    So your client finds out what it's like to ignore your expert advice. Sounds like you've already warned them, I'd leave it there.
    – Nathan
    Commented Dec 19, 2015 at 22:57
  • @AmrinderArora It's a Java web application running on Hibernate. I'm sure most of the Hibernate queries will work if the dialect is set correctly. Unfortunately the app does have a lot of native queries. It's these that I'm sure will break.
    – Barry A.
    Commented Dec 20, 2015 at 0:39

3 Answers 3


Directly and honestly.

By the way, I think, this is a sales and negotiation question:

As far as I understood, you would like to support your customer and maybe earn some money. You would like to do both by predicting the future and you are (for whatever reason, time in your situation) not able to prove your prediction.

What is the worst case outcome?

Everything goes smoothly and your customer doesn't believe in your experience any more.

Or: Your customer has a lot of problems and claims you didn't warn him enough.

Find a way to deal with both:

For example, offer to perform a partial move of the DB to see how it works and let your future involvement depend on the result.

Offer a time based contract instead of a fixed price one.

The important point:

  • Take his beliefs seriously
  • Explain yours
  • Provide a scaleable solution to move with minimum effort from the scenario predicted by him to the scenario predicted by you

By the way, it could help to point out the risks, including consequences, if your prediction comes true while your customer continues his way.

  • Thanks for answer. Ironically, we've tried something like this years ago to save money on MSSQL. Most of the CRUD pages work but once you hit a page with some kind of complex query, MySQL just balked. We decided it was cheaper to continue paying for MSSQL that rewrite all those queries.
    – Barry A.
    Commented Dec 20, 2015 at 0:43

Ask them to run this simple prototype:

  1. Copy the existing production DB (in MySQL) to a new test DB (in MS SQL)
  2. Create a test version of the application (in Java)
  3. Connect the test version of the application to the test DB

At that point, either the client will figure out that many pages are broken, or you will figure out that the way they have their application, it is mostly or entirely DB agnostic (a possibility, even if one with lower probability). Either way you guys will converge on the next steps.

  • 1
    I'd call this a "prototype" or "story spike." Sounds better than test to me, but your mileage may vary. Otherwise, very pragmatic advice.
    – Todd A. Jacobs
    Commented Dec 21, 2015 at 16:04

We had a similar situation (idea to migrate Oracle to Postgre though). A meeting with a seasoned and reputable DBA and client helped a lot.

  • 1
    I love meetings with seasoned and reputable DBAs. But since I missed that one, could you just tell us what they said? :-) Commented Dec 25, 2015 at 0:10

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.