Five questions every government CIO should ask before signing.

The day you sign a multi-year enterprise software contract is the most expensive day of the contract. Not because of the money you commit on day one, but because of the questions you did not ask before signing.

I have sat on both sides of this table. As an implementer for the past thirteen years across thirty-plus deployments, and now as the founder of a company that sells the kind of software being discussed. The same five questions come up in every difficult mid-contract conversation. They are also the five questions that, if asked clearly during procurement, would have prevented the problem entirely.

None of these questions are technical, exactly. They are operational. They are the questions that test the structural shape of what you are about to commit to — whether what you are buying is a tool your team will own, or an arrangement your team will be owned by.

— QUESTION 01 Who configures a new permit type in year three?

This is the most important question, and the one most CIOs do not ask in the form they should.

Every government agency adds new service categories, new permit types, new fee structures, new approval chains over time. This is not unusual. It is the operating reality of government — statutes change, regulations evolve, new mandates arrive, new revenue streams open. The question is not whether your team will need to add a new permit type or service category. The question is who does the work when it happens.

The marketing answer most vendors give is "the platform is configurable." This is almost always true at a trivial level (you can change the logo, the color, the field labels) and almost always false at the level that matters. The level that matters is: can your in-house team, three years after go-live, add a new permit class with its own fee schedule, prerequisite checks, multi-department review chain, inspection regime, and certificate template — without filing a change request with the vendor, without engaging professional services, and without waiting for the next quarterly release?

If the honest answer is no, you are not buying a configurable platform. You are buying a customized installation of a platform, with a long-term professional services dependency built in. The total cost of ownership is two-to-five times the licensing fee, and the dependency is structural, not optional.

The good answer to this question looks like this: "Your team configures new permit types as part of their normal operations. We trained your team on this during implementation, three of them are now certified, and our role going forward is to support the platform — not to add functionality your team should be adding."

The evasion to listen for: "We have a very flexible configuration framework, and our services team can rapidly stand up new categories for you." This is a polite description of the dependency.

— QUESTION 02 What does year seven look like?

Most enterprise software contracts have an initial term of three to five years. The vendor's incentive structure is heavily weighted toward initial deployment, with renewal economics that depend on switching costs being high enough that you cannot reasonably move. This is not malice. It is structure.

Year seven is the inflection point. By then, you have lived with the platform long enough to know its limits, you have made operational commitments that depend on it, and you are facing a renewal or a re-procurement. If you decide you need to move, can you?

The structural conditions for being able to move are specific. Your data must be extractable in standard, documented formats. The schema must be public, not proprietary. Your business configuration — the metadata that defines your permit types, your approval chains, your reports — must be portable: exportable, readable, and theoretically rebuildable on a different runtime. Your integrations must use open standards (REST, GraphQL, SAML, OIDC) rather than proprietary protocols, so the systems that talk to your platform can be repointed.

Ask: "If I decide in year seven to migrate to a different platform, what is the structural plan? Specifically, can my team export every data record, every configuration, every workflow definition, in a form that is documented and standard?"

The good answer is detailed and operational. "Your data lives in a documented relational schema you can query directly. Your metadata is exportable as JSON or YAML against a published schema. Your integrations are REST and GraphQL with OpenAPI specs. None of this is proprietary."

The evasion to listen for: "Our customers don't leave us, so this isn't really a question we need to answer in detail." This is not an answer. This is what a vendor says when the answer would embarrass them.

— QUESTION 03 Where, precisely, does our data live?

"In the cloud" is not an answer. "In a sovereign-cloud region" is closer. "In the following named data center facility, operated by the following named entity, under the following jurisdiction" is the answer.

Data sovereignty has moved from procurement preference to procurement requirement in most jurisdictions over the past three years. The shift was driven by a combination of explicit regulation (GDPR transfer rulings, sectoral data localization laws in India, the UAE, KSA, and elsewhere), strategic concerns about extraterritorial legal claims (the US CLOUD Act, similar provisions in other major cloud-hosting jurisdictions), and the simple operational reality that government systems holding citizen data should not be hosted in third-country jurisdictions.

You need to ask the question at three levels. Where is the primary data store hosted? Where are the backups? And critically, where are the encryption keys?

The last question matters more than most procurement officers realize. If your encryption keys are held by a cloud vendor in a jurisdiction outside yours, then your data is effectively accessible to that jurisdiction's legal claims, regardless of where the encrypted data itself is stored. Customer-managed keys are the technical mechanism that preserves sovereignty. Hardware security module integration is the strongest version of this.

Good answer: "Your data lives in [named jurisdiction] in [named facility]. Backups are in a secondary site in the same jurisdiction. Encryption keys are customer-managed; we never see your plaintext data; you can rotate keys without our involvement."

Evasions to listen for include any answer that involves the word "globally," any answer that says "we can deploy in your region but our control plane is elsewhere," and any answer that uses the phrase "industry-standard encryption" without addressing key management.

— QUESTION 04 How is your team stronger after the contract than before?

This is the question most procurement frameworks do not have a field for, and most CIOs feel awkward asking, because it sounds soft. It is not soft. It is the question that distinguishes a healthy long-term software relationship from a parasitic one.

Every multi-year government IT engagement either builds your team's internal capability or erodes it. There is no neutral. If the vendor handles every customization, every integration, every report change, every new requirement, then over time your team becomes a queue of tickets to the vendor — not the operators of the system. When you reach the next procurement cycle, your team has less institutional knowledge than they had at the start. The vendor has more.

This is what I call capability capture: the structural transfer of operational knowledge from the customer to the vendor over the life of the contract. It is rarely an explicit intent; it is the natural consequence of a contract structure that rewards the vendor for handling work the customer's team could do.

The opposite pattern — capability transfer — is structurally different. The contract includes specific capability transfer milestones: by month six, your team has been trained and certified on configuration. By month nine, your team is leading new permit-type configurations with vendor support, not the other way around. By month twelve, the vendor's role has shifted to platform support and edge-case advisory, while your team owns operational changes.

Ask: "What is the capability transfer plan? Specifically, what certifications will my team hold by which milestone, and what work will they own by the end of year one?"

The good answer includes specific role profiles, named certifications, named milestones, and a clear statement about what your team will own. The evasion to listen for: "We provide comprehensive training as part of every implementation." Training is not transfer. Knowing how to log into the admin console is not the same as being able to add a new permit type without engaging the vendor.

— QUESTION 05 Show me a customer who left.

This is the final question, and it is the most diagnostic. Every vendor will show you reference customers who are happy with their platform. Few will show you a customer who left, what the migration looked like, and what they learned.

The reason matters. A vendor whose customers never leave is either an exceptional vendor, or a vendor whose customers cannot leave. The two states look identical from the outside; they are completely different on the inside. The first reflects a healthy product-market fit. The second reflects structural lock-in that has not yet been tested by anyone with the political will to test it.

What you are looking for is a vendor who has had a customer leave, who can describe the migration honestly, who can tell you what worked and what did not, and who is professionally aligned enough with the customer's interests that the migration was not weaponized.

This is also the question that calibrates everything else the vendor has said. A vendor who claims that data is fully portable, configuration is fully exportable, and integrations use open standards should be able to point to an actual case where these claims were tested. If they cannot, the claims are aspirational.

Ask: "Has a customer ever migrated away from your platform? What did that look like? Can I speak to them?"

The good answer involves honesty. "Yes, [named customer] migrated to [named system] in [year]. They left because [honest reason]. The migration took [duration]. We exported their data and configuration in standard formats. We are happy to make an introduction so you can speak with them directly."

The evasion to listen for: any version of "We have not had a customer leave." This is a feature, not a bug, only if the underlying reason is product satisfaction. If it is structural lock-in, it is the most expensive bug in the contract you are about to sign.

— CONCLUSION These questions are specific on purpose.

None of these questions is hard for a vendor who has built their product and their commercial model around the customer's long-term interests to answer. Each of them is impossible for a vendor who has not. That asymmetry is the entire point. The questions are calibrated to distinguish the two patterns.

I have written them down because I have watched too many government IT engagements drift into expensive, multi-year arrangements that would have been recognized as the wrong shape if the questions had been asked at the start. The questions are not a magic filter; a sufficiently practiced vendor can give plausible-sounding answers to all five. But the way the answers are constructed — their specificity, their honesty about edge cases, their willingness to name customers and milestones — tells you what kind of partner you are about to commit to for the next three to seven years.

Ask them. Write down the answers. Then ask whether the contract you are about to sign actually delivers what the answers promised.

Salman Farees is the founder and CEO of Emeron Infospace, a UAE-based government-technology platform company. He has spent the past thirteen years implementing enterprise software for government and public-sector customers across MENA and Africa.