Every modernisation proposal looks good on page one. There is a confident timeline, a diagram with arrows pointing towards "the cloud", and a team slide full of smiling people you may never meet again after the kickoff.
If you run technology at a mid-sized company in the UAE, you will probably sit through several of these pitches before you choose a partner to help modernise a legacy system. The proposals start to blur together. The differences only show up six months later, when the plan meets your actual database.
Here are the questions that tend to separate a partner who will finish the job from one who will finish the slide deck.
1. "What will you need from us in the first month?"
A good partner knows the project depends on your people as much as theirs. If the answer is "nothing, we'll handle everything", be careful. Nobody can modernise a system they cannot ask questions about.
What to do: ask for a named list. Which of your people, how many hours a week, which systems they need access to, and by when. If they cannot tell you this before you sign, they have not thought about your project yet. They have thought about a project.
2. "How will you learn what the current system actually does?"
The documentation is out of date. It always is. The real rules live in stored procedures, scheduled jobs, and the head of someone in Finance who has been there since 2011.
What to do: ask how they run discovery. Listen for words like tracing real transactions, reading the code, profiling the data, and sitting with the people who use it. Be wary of "we'll review your documentation" as the whole answer.
3. "What is the first thing that goes live, and when?"
A plan where nothing reaches production for nine months is a plan to discover problems late and expensively.
What to do: ask them to name the first small, real change they would ship, and roughly when. A faster report, one integration moved behind an API, one module running on the new stack. If the first release is "everything, in phase three", push back.
4. "Would you rewrite this, or replace it in pieces? Why?"
There is no single right answer, but there should be a reason. A partner who always recommends a full rewrite, whatever the system, is selling a method rather than solving your problem.
What to do: ask them to walk through the trade-offs for your system specifically. How long would you run old and new side by side? What happens to changes requested during the project? What would make them change their recommendation?
5. "Who exactly will be working on this?"
The senior architect in the pitch meeting is impressive. The question is whether you will see them again after week two.
What to do: ask for the names and roles of the actual delivery team, and how much of their time is committed to you. Ask to speak with the person who will lead it day to day, not only the person selling it. Agree in writing what happens if key people are swapped out.
6. "How do you handle data residency and our regulator?"
In the UAE, where your data lives and who can reach it matters, especially in banking, insurance, healthcare and government-linked work. These questions should come up in the first conversation, not the week before go-live.
What to do: ask which cloud regions they plan to use, how they handle production data in test environments, and whether they have worked with your sector's rules before. If they need to "check with the team" on all of it, note that.
7. "How will we know it is working, before the project ends?"
Status reports full of green ticks feel reassuring right up until they don't. Percent complete is not an outcome.
What to do: agree on a small set of measures you can both see, such as release frequency, how long key jobs take, incidents on migrated parts, and one business number the owner already tracks. Ask how often they will report against those, and what happens when one moves the wrong way.
8. "What happens when you leave?"
Every engagement ends. The worst outcome is a shiny new system that only the vendor understands, which is the same problem you started with, just more modern.
What to do: ask how knowledge transfers to your team during the project, not just at the end. Who owns the code and the cloud accounts? Will there be documentation that describes the system as built, and runbooks your team has actually used? Ask to see an example of a handover from a previous project.
A quick way to compare proposals
Put the answers side by side in a simple table. One row per question, one column per partner. You are not looking for the most polished answer. You are looking for the most specific one.
Specific answers name people, dates, systems and trade-offs. Vague answers name values. "We're agile and customer-focused" is a nice sentence. It is not a plan.
Also ask each partner for one reference from a project that went badly, and what they changed afterwards. Every team has one. The honest ones will tell you about it.
The point of asking
Choosing a modernisation partner is really choosing who you will be stuck in a room with when something goes wrong at month four. The questions above will not guarantee a smooth project. They will show you, before you sign, how a team thinks when the answer is not on their slide.
If you have hired for one of these projects, which question do you wish you had asked earlier?
Originally published on LinkedIn by Latent Digital Solutions FZCO. Learn more at latentdigitalsolutions.com.
