What Should Enterprises Check Before Choosing an IT System Integrator for a Major Infrastructure Project
An IT head shortlists three system integrators for a new data center and network refresh. All three show similar case studies, similar OEM certifications, and pricing within a few percentage points of each other. The team picks one, largely on relationship history and a confident sales pitch. Fourteen months later, the project is behind schedule, the resourcing on site has changed twice, and nobody on the buyer's side can say with confidence who is accountable for the delay.
This is not a rare story. It is closer to the median outcome. Research from McKinsey and the University of Oxford, covering more than 5,400 large IT projects, found that projects with initial budgets above 15 million dollars run 45 percent over budget and 7 percent over time on average, while delivering 56 percent less value than originally promised. The same research found that each additional year a project runs adds roughly 15 percent to its cost overrun, and that 17 percent of these projects go so badly wrong that they threaten the existence of the company that funded them. The technology rarely fails on its own. The partner selection process usually does.
Key Criteria for Selecting an IT System Integrator
Enterprises evaluating a system integrator for a major infrastructure project should weight the decision toward four things that price sheets and case study decks do not reveal on their own: verified delivery methodology, compliance and empanelment status relevant to the industry and region, financial and resourcing depth to sustain the engagement, and contract terms that define exit, SLA penalties and data ownership before the relationship begins, not during a dispute. Brand familiarity and OEM logos on a slide are among the least predictive signals in the entire process, and treating a long standing or affiliated partner as automatically low risk is, as the case study below shows, one of the more expensive mistakes a large organization can make.
The current state of system integrator selection in enterprise IT
India's IT spending is expected to reach 176.3 billion dollars in 2026, a rise of 10.6 percent over 2025, and the data center systems segment is projected to grow 20.5 percent, faster than any other category as enterprises build out AI ready compute, storage and networking. Gartner attributes this to accelerating cloud and digital adoption combined with a wave of new AI infrastructure investment across Indian enterprises. Public cloud spending in India is forecast to grow 28.1 percent to 17.5 billion dollars in 2026, with infrastructure as a service alone expected to grow around 40 percent. Information security spending is projected at 3.4 billion dollars, up 11.7 percent, and managed security services are the fastest growing subsegment within that budget, expanding around 15.1 percent as enterprises look for scalable ways to handle rising threat complexity.
That growth means more enterprises are issuing infrastructure RFPs at the same time, often to the same pool of qualified integrators, which compresses timelines and increases the temptation to shortlist quickly on reputation rather than run a full due diligence cycle. The volume of spend also means the cost of a wrong choice is climbing in absolute terms, not just in percentage overrun.
Why this decision carries more risk than most IT purchases
Buying a system integrator is different from buying software or hardware. A software purchase can usually be reversed. A system integrator engagement, once it involves physical infrastructure, network redesign, migrated workloads and staff who have learned an environment, is expensive and disruptive to unwind midway. Independent analysis of ERP programs, which share many of the same delivery risks as infrastructure projects, puts failure rates against original objectives between 55 and 75 percent, with poor vendor selection consistently named as a top contributing factor. Older PMI research had already put a number on the ambient cost of this: organizations waste close to 9.9 percent of every dollar they invest in projects because of poor project performance, a figure that compounds quickly across a multi year infrastructure program.
Downtime during a poorly managed migration or cutover also has a direct financial cost. ITIC's 2024 survey of more than 1,000 firms found that over 90 percent of mid-size and large enterprises now report an average cost above 300,000 dollars for a single hour of downtime, and 41 percent report losses between 1 million and 5 million dollars an hour. Uptime Institute's most recent outage analysis found that 54 percent of significant outages cost more than 100,000 dollars, and one in five exceed 1 million dollars. A rushed integrator selection increases the odds of exactly this kind of event during transition, and the case study below is one of the clearest public examples of how that plays out at scale.
Case study: what happens when capability assessment is skipped
In April 2018, UK retail bank TSB migrated more than 5 million customers and 1.3 billion records onto a new core banking platform called Proteo4UK, built and delivered by Sabis, the IT services arm of its parent company Sabadell. The migration failed within hours of going live. Up to 1.9 million customers were locked out of their accounts, some customers were able to view other people's balances and transactions, and outages and data problems continued for weeks afterward.
An independent review by law firm Slaughter and May, commissioned by TSB itself, found that Sabis was not ready to operate Proteo4UK when the switch was made, and that testing had been carried out offline rather than in a live environment, which meant problems were never caught before go live. The review also found roughly 2,000 defects were known at the point of launch, while the board had reportedly been told about fewer than 800. Perhaps the more instructive finding for anyone running a vendor selection process today was this: TSB had not properly assessed Sabis's delivery capability the way it would have assessed an external third party, largely because Sabis was part of the same corporate group. The review concluded the relationship should have been managed at arm's length regardless of ownership, given the scale and criticality of the program.
The financial and regulatory consequences were substantial. TSB reported total costs of £330 million from the failure, covering customer compensation, fraud losses, additional resourcing and lost income, and the bank posted a £105.4 million loss for 2018 against a £162.7 million profit the year before. The UK's Financial Conduct Authority and Prudential Regulation Authority later fined TSB £48.6 million for failing to organize, control and govern the migration program and its outsourcing risk adequately. TSB's own IT provider was billed roughly £153 million toward the cost of the failure. Within two years, TSB had abandoned managing the platform relationship in house and brought in IBM as a new system integrator, in a deal reported to be worth around 1 billion dollars, and the bank's chief executive resigned in the aftermath.
The lesson for any enterprise running a system integrator RFP is not that affiliated or long standing partners are automatically wrong. It is that governance, capability verification and live environment testing cannot be waived because a relationship feels familiar or low risk on paper. The two organizations that were closest to each other on the org chart were the two organizations that skipped the diligence a genuine third party evaluation would have forced.
What actually separates a strong system integrator from a weak one
Technical depth versus certifications on paper
OEM partner badges, from Fortinet, Cisco, Microsoft, AWS and similar vendors, confirm that a firm has trained engineers and can resell products. They do not confirm that the firm has delivered a project of comparable scale and complexity to the one being planned. Ask for the names and role tenure of the engineers who will actually be assigned, not the certification count the company holds in aggregate. Ask to see a redacted architecture diagram, a runbook and a test plan from a comparable past project, not just a summary slide. A firm with fifty certified engineers can still assign three juniors to a critical project if resourcing is not specified in the contract.
Delivery methodology and project governance
Ask how the integrator structures a large project: stage gates, change control boards, RAID logs (risks, assumptions, issues, dependencies) and who owns escalation when a milestone slips. Ask specifically whether testing will happen in a live or production representative environment before cutover, since TSB's own review identified offline only testing as one of the direct causes of its failure. A firm that cannot describe its own delivery framework in specific, documented terms is unlikely to bring one to your project.
Compliance, empanelment and regulatory readiness
In India, this is no longer optional for regulated sectors. Most banking, NBFC, payment aggregator, government, telecom and capital markets tenders now include a clause requiring the security auditor, and often the integrator, to hold current CERT-In empanelment, which is granted for a defined three year period and must be renewed. CERT-In's 2022 directions, issued under Section 70B(6) of the IT Act, require organizations to report specified categories of cyber incident within six hours of detection and to retain ICT logs for 180 days, obligations that a system integrator managing your infrastructure needs to be built to support from day one. RBI's 2026 supervisory directions go further for regulated financial entities, requiring banks to assess both the firm level and personnel level credentials of any empanelled auditor or partner at every selection and renewal cycle, not just at onboarding.
Data privacy adds another layer. India's DPDP Rules 2025 were made official in late 2025 and give enterprises up to 18 months to bring their data handling into compliance. Any integrator touching customer or employee data as part of an infrastructure project should be able to describe, specifically, how their deployment practices support that compliance timeline rather than create new gaps in it.
Financial stability and resourcing depth
A firm that looks strong on a case study slide can still be financially thin. Ask for basic financial disclosures, current headcount against current project load, professional indemnity or errors and omissions insurance cover, and references from clients whose projects ran for a comparable duration, not just the two best case studies the sales team leads with. A structured, criteria based evaluation process matters here in a measurable way. Enterprises that run scenario based, scorecard driven vendor evaluations report a 45 percent lower vendor failure rate within 18 months compared to those that select informally.
Contract structure, SLAs and exit terms
This is the section most committees rush through, and it is the one that determines how expensive a bad decision becomes. Define uptime and response SLAs with financial penalties attached, not aspirational language. Define who owns configuration documentation, credentials, source code and architecture diagrams during and after the engagement, and make sure that ownership is explicit rather than assumed because of a corporate or reseller relationship. Define a clear exit and transition clause before signature, including a maximum handover period to a replacement partner if the relationship ends, and a data portability clause that survives termination. Enterprises that skip this step often discover, only after a dispute begins, that the integrator holds effective control of documentation and access that should belong to the enterprise, which is close to what happened to TSB when it needed to bring in a replacement integrator under crisis conditions rather than a planned transition.
The data behind infrastructure project risk
It is worth putting the numbers side by side, because they tell a consistent story rather than three unrelated ones.
Large IT projects run 45 percent over budget and 7 percent over time on average, and deliver 56 percent less value than predicted, with every additional year of duration adding roughly 15 percent to the overrun.
Seventeen percent of large IT projects become what researchers call black swans, defined as budget overruns above 200 percent, severe enough to threaten the survival of the funding organization.
PMI's 2025 Pulse of the Profession found close to 80 percent of enterprise projects met their business goals, meaning roughly one in five materially did not.
The Standish Group's long running CHAOS research has consistently found around 19 percent of IT projects fail outright and more than half are challenged, a pattern that has changed little across nearly a decade of updates.
Fifty five to 75 percent of ERP implementations fail to meet their original objectives, with poor vendor selection cited as a leading contributor.
None of these figures are about technology failing on its own. They are about scope discipline, governance and partner accountability failing, exactly the layer a rigorous system integrator selection process is designed to protect, and exactly the layer that broke down in the TSB case.
What enterprises should do before issuing an RFP
Define outcomes and success metrics before writing requirements, so vendors are scored against business results rather than feature checklists.
Require CERT-In empanelment status, or the equivalent regulatory clearance for your sector, as a technical eligibility gate, not a nice to have.
Ask for named engineers, not aggregate certification counts, and verify their availability for your project timeline.
Require a live or production representative test plan for any cutover, and ask how defects found close to go live will be reported to your steering committee.
Score references on projects of comparable scale and duration, and call at least one reference that was not supplied by the vendor if possible.
Negotiate SLA penalties, documentation ownership, data portability and exit terms before selection, not after.
Build in a stage gate review at 25 percent and 50 percent project completion so problems surface early rather than at go live.
Apply the same level of scrutiny to an affiliated, incumbent or long standing partner that you would apply to a completely new vendor.
Where NS3TechSolutions fits into this evaluation
NS3TechSolutions works with enterprises across IT infrastructure, enterprise networking, cybersecurity and network security, cloud, managed services and SOC and NOC operations, often as a Fortinet partner supporting network security deployments alongside broader infrastructure work. The value in that kind of partner is not the badge on the website. It is the ability to sit across infrastructure, security and managed services in one accountable relationship, so an enterprise is not stitching together three separate vendors and three separate escalation paths for one project, and does not end up discovering documentation gaps or ownership disputes the way TSB did when its relationship with its own IT provider went wrong. For IT leaders running the evaluation described above, that kind of consolidated accountability is one of the more practical ways to reduce the governance gaps that show up in the failure statistics cited throughout this piece.
Practical checklist to save or share internally
Confirmed CERT-In empanelment or sector specific regulatory clearance, verified independently, not just claimed
Named delivery team with role tenure and current utilization
Documented delivery methodology with stage gates, change control and a RAID log approach
A committed live or production representative test plan ahead of any cutover
Minimum of two verifiable references on comparable scale projects
Defined SLA penalties tied to uptime and response times
Documentation, credential and data ownership defined explicitly in the contract
Exit and transition clause with a maximum handover timeline
Data handling practices mapped against DPDP Rules 2025 obligations
Financial stability and insurance cover checked against current project load
The same diligence applied to affiliated or incumbent vendors as to new ones
FAQ
Q. What is the difference between a system integrator, a VAR and an MSP?
A. A VAR primarily resells hardware and software. An MSP manages ongoing operations after deployment. A system integrator designs, deploys and integrates multiple technologies into a working environment, and many established firms now operate across all three roles, which is itself worth clarifying before you sign.
Q. Is CERT-In empanelment mandatory for every IT infrastructure project in India?
A. It is not universally mandatory, but it is a common technical eligibility requirement in banking, government, telecom and capital markets tenders, and it signals a baseline level of technical vetting even where it is not contractually required.
Q. How long should a system integrator selection process realistically take?
A. For enterprise infrastructure and strategic partnerships, three to six months is typical once RFP complexity, stakeholder alignment and negotiation are accounted for. Rushing this timeline is one of the more common root causes of later delivery problems.
Q. What happens if a system integrator project fails midway?
A. Recovery depends almost entirely on what was defined in the original contract. Enterprises with clear documentation ownership, exit clauses, and SLA penalties can transition to a new partner in weeks. Enterprises without them can spend months disputing access to their own environment, as TSB experienced before it eventually brought in a new integrator under crisis conditions.
Q. How many integrators should be shortlisted for a major RFP?
A. Three to five is generally enough to allow meaningful comparison without making the evaluation unmanageable for a committee running structured scorecards.
Q. What SLAs matter most in a system integrator contract?
A. Uptime commitments with financial penalties, incident response and resolution times, and a defined escalation path with named individuals rather than a generic support desk.
Q. Should price be the deciding factor in system integrator selection?
A. No. Given that 45 percent budget overruns and 56 percent value shortfalls are the documented average on large IT projects, the lowest bid is frequently the most expensive choice once delivery risk is priced in.
Q. Does it matter if the system integrator is affiliated with or part of the same group as the buying organization?
A. It matters more, not less. The TSB case shows that affiliated or incumbent relationships are sometimes assessed less rigorously precisely because they feel familiar, which removes the arm's length scrutiny that catches capability gaps before they become live outages.
Conclusion
Choosing an IT system integrator for a major infrastructure project is not a procurement exercise that ends with a signed statement of work. It is a governance decision that determines how much of the McKinsey and Oxford overrun statistics, or the PMI and Standish failure data, your organization is exposed to over the life of the project. TSB's experience is a reminder that even a partner that looks like the obvious, lowest friction choice still needs to be assessed and managed as rigorously as any outside vendor. The enterprises that avoid becoming part of these numbers are the ones that verify delivery methodology, compliance status, resourcing depth, live environment testing, and exit terms before the contract is signed, not after the first milestone slips.