Hiring an outside team to migrate a mainframe is a large decision with few easy ways to check the answers you get. These questions are meant to be asked of any provider, including us. For each one we describe what a solid answer looks like and what should worry you.
How will you find out what the system does?
A solid answer describes an assessment: an inventory of code, jobs and data, analysis of what actually runs, interviews with the people who operate it and tests that record current behavior. It says which parts rely on tools and which on manual review.
Be careful when a price and a schedule arrive before anyone has looked at the system. Whatever sits behind such a quote is assumptions, and you should ask to see them written down.
Ask who will do the assessment, too. The people who examine your code should be the people who plan the migration, not a sales team handing off to strangers, because the details they notice shape every later decision.
How will old and new run together?
Ask for the method in specific terms. Does the new component run in parallel with the old one while outputs are compared? Who reviews the differences? What are the rollback points, and what must stay running to make rollback possible?
A plan that depends on a single cutover weekend, with no route back, concentrates risk in a few hours. Incremental methods such as a parallel run reduce that risk, though not to nothing, and an honest provider will say so.
Ask what "done" means for the old system. A decommissioning step, with a defined set of checks that must pass over an agreed number of cycles before anything is switched off, is much safer than a date on a calendar.
Who touches our code and data, and where?
Settle this before any file moves. A mutual NDA should come first. Access should run through your controls, with the work done in your environment or one you approve, and with logging of who accessed what. Ask where people work and whether subcontractors are involved.
Ask also whether the work can use masked or synthetic data, so that real customer records are not needed for most of it. Your security and compliance teams, not the provider, define what is acceptable. A provider should adapt to your rules, and should never claim a certification as a substitute for your own review.
If the provider proposes tools that run inside your network, ask what data they collect and where it goes. Tools that send code or logs to an outside service need approval from your security team first.
What happens when the plan changes?
The plan will change, because old systems hold surprises. Ask how change is handled: how assumptions are recorded, what triggers a re-estimate, who approves it and where decision points fall between phases. A written change process protects both sides from arguments about what was agreed.
Ask about exit too. If you stop after the assessment or after a phase, do you keep the documentation, tests and roadmap in a form another team could use? Work that belongs to you whether or not the relationship continues is a good sign.
What will they not promise?
This may be the most revealing question. No one can honestly promise zero downtime, fixed savings or a delivery date before assessing the system, and a provider who does is either guessing or selling. A better answer lists the conditions under which a promise could be made: what has to be known first, and what would change the number.
A good provider will also tell you when not to migrate. Retaining a stable system, wrapping it with APIs or retiring parts of it are real options, and a plan that never considers them is incomplete.
A practical way to use this list is to send the same questions to every provider you consider, in writing, and compare the answers side by side. How specific the answers are usually tells you more than what they say. Vague answers to concrete questions are a signal in themselves, and so is a provider who is happy to put assumptions on paper before any contract is signed.
For how we answer these questions ourselves, see mainframe modernization and AWS mainframe modernization. If you want to talk through your own list, use the contact page.
A note on limits: tools, cloud services and practices change, and results depend on the system. Use these questions as a starting checklist and add your own.