5 Questions to Ask Before You Hand Over Your Infrastructure Upgrade

A proposal document will not tell you whether a partner can actually deliver your infrastructure project. Every proposal looks good. What separates vendors who deliver from vendors who struggle is how they answer five specific questions before you sign anything. I ask versions of these in every vendor evaluation I run.

1. Can You Show Me a Comparable Project You Have Delivered, From Design Through Go-Live?

Not a reference call -- a documented case. Reference calls are rehearsed. What you want is evidence: a project scope, an architecture diagram, a go-live timeline, and ideally a post-implementation review. If a vendor cannot show you documented evidence of a similar project, they are asking you to be one of their more complex early deployments. That may be acceptable if the pricing reflects it. Usually it does not.

The comparable project does not have to be identical to yours. It needs to be similar enough in scale, technology, and complexity that you can draw reasonable inferences about their capability. A partner who has delivered fifteen Citrix deployments for 300 to 500 user organizations is credible for your 400-user project. One whose reference projects are all 50-user environments is not.

2. Who Owns the Outcome When the Architect Is Not the Person Doing the Work?

This is the question that exposes the gap between what partners sell and what they deliver. A senior architect designs your solution. A less experienced engineer implements it. That is standard practice in this industry, and it is not inherently a problem -- as long as there is clear accountability for the outcome and a review process that catches implementation drift before go-live.

Ask specifically how they bridge design and implementation. Who reviews implementation work against the design? Who is the escalation point when the engineer runs into something the design did not account for? If the architect and the implementation engineer never talk, you will find out about design-implementation gaps during your production deployment, not before.

3. What Is Your Definition of Done?

A working deployment is not done. Done includes user migration completed, runbooks written and reviewed, IT staff trained on day-to-day operations, and a handoff that your team can actually operate from. I have seen organizations receive a technically functional system from a vendor and spend the next three months reverse-engineering how it works because the documentation did not exist.

Ask for a sample deliverables list from a completed project. If it includes a working environment and little else, the definition of done is not aligned with what you actually need.

4. How Do You Handle Scope Changes During the Project?

Every infrastructure project encounters something that the design did not anticipate. The question is not whether scope will change -- it will. The question is how the partner manages it. Do they have a formal change control process? How are changes priced? Who approves them? What happens to the timeline when a change is approved?

Partners who do not have clear answers to these questions tend to handle scope changes in one of two ways: they absorb them silently and cut corners elsewhere to stay on budget, or they surface them at the end of the project as a surprise invoice. Neither outcome is good for you.

5. What Happens After Go-Live?

The weeks immediately after go-live are when most infrastructure problems surface. Users encounter edge cases. Performance behaves differently under real production load. Configuration issues that did not appear in testing appear now. A partner who disappears at go-live leaves you handling those issues alone with a system you did not build.

Ask specifically: what does the post-go-live period look like? Is there a structured hypercare window with defined support availability? Who is the contact and what are the response time expectations? How long does that period last? The answers reveal whether the partner considers delivery complete at go-live or at stable operations -- and those are very different definitions.