I know I have written a lot about AI lately. I am still a CIO for multiple clients, and that work still gets done (it just does not get written about as often). I am working on writing more posts for my non AI work.
My AI minions learned to dig through a former CIO’s archived email and pull out contracts nobody has opened in years. One step closer to world domination… but first, someone has to read the folder labeled “Telecom Misc.”
That folder is where I found the telecom contract that stopped a network deployment I had already scoped, budgeted, and queued. Warren, my document extraction minion, surfaced it during a routine sweep of a former CIO’s archived mailbox. The term runs three years and expires more than a year from now. Nobody currently at the organization knew it existed.
This post is about the specific, infuriating way a telecom contract becomes an invisible infrastructure constraint. The contracts themselves are rarely complicated. The problem is that nobody reads them after signing, nobody tracks the end dates, and nobody connects the telecom renewal calendar to the infrastructure roadmap. You find out when a project runs into the wall.
Telecom Contract Management and the Gap Nobody Talks About
Here is the scenario. You take over as CIO at a multi-site organization. The previous IT leader ran the place for years. Your roadmap includes a WAN modernization project with new switches, new access points, and a Meraki SD-WAN deployment at the primary site. The work is scoped, budgeted, and in the queue.
Then Warren finds a contract.
It is with a SIP trunking vendor and covers POTS replacement and SIP trunking for the primary site. The term is three years. The monthly commitment triggers an early termination fee if the service is cancelled before the term ends.
The Meraki design changes how voice traffic is routed. You cannot restructure voice routing without touching the SIP trunk configuration. You cannot touch the SIP trunk configuration without risking the termination clause. The project was not blocked by technology or budget. It was blocked by an agreement nobody in the current organization had ever seen.
That is the gap. The infrastructure roadmap and the telecom contract calendar had never been in the same room.
The Moment the Project Stopped
I wish I could say I caught this in planning. I caught it in the design review.
I was walking through the voice traffic flow for the primary site, the part of an SD-WAN design that always looks simple on a diagram and never is in production. The question was where the SIP trunks would terminate once the new edge devices were in place. I asked for the trunk configuration and the contract behind it, expecting a quick answer. Nobody had either. Finance could show me a monthly invoice. The telecom team, which is a generous name for one person who had left, had never documented the term.
That is when I asked Warren to run an extraction across the archived mailbox. Warren found the executed agreement in about ten minutes. It had been sitting in a folder for more than a year.
That should have been step one of the project, not step nine.
How the Contract Stayed Hidden
The contract had been signed more than a year before I found it. In that time it was never reviewed, never renegotiated, and never opened by anyone building the infrastructure roadmap. It was billed monthly and forgotten.
The reason is structural. Telecom contracts get signed, then they get filed, or in this case emailed to a CIO’s inbox and never moved to shared documentation. The finance team sees a monthly line item. The infrastructure team sees a technical project. Nobody owns a process that says “before we plan a network change, check which telecom contracts are running.”
This is not stupidity. It is a silo problem. Telecom sits in procurement and finance. Network infrastructure sits in IT engineering. Contract calendars sit in legal or admin. When those functions never compare notes, infrastructure plans run straight into contract walls.
I have seen this exact failure at three different organizations. A cable franchise agreement blocked a data center relocation. A managed MPLS contract prevented a cloud migration. Now a SIP trunking agreement is gating a Meraki deployment. The vendors and services change every time. The failure does not. The contract calendar was never connected to the project roadmap.
Who Actually Owns the Contract Now
There is a second wrinkle worth understanding if you do this kind of forensics. The company that signed the agreement is not quite the same company anymore.
This vendor had been acquired years earlier by a much larger cloud communications company. The acquisition gave the parent a nationwide voice network. It gave the original vendor’s customers a new owner they had never heard of and a support structure that looked nothing like the regional relationship they signed up for.
Contracts survive acquisitions. The terms, pricing, and service commitments are still enforceable. What changes is everything around them. At renewal you negotiate with the parent’s business unit. When you escalate a service issue, you navigate a support model built for a global company, not the regional provider your predecessor chose. When you decide whether to renew or migrate, you need to understand where the parent is taking its product line, not just how the subsidiary performed in the past.
None of this is disqualifying. It is information, and you only get it if you read the contract and research who owns the counterparty.
What I Did Next
Warren’s extraction run surfaced eleven documents in that folder. Three were relevant contracts. Eight were vendor marketing materials that never got deleted. Once the SIP agreement was flagged, I did three things right away.
First, I read the early termination clause. I needed to know whether the fee was flat, a percentage of remaining contract value, or a month-count formula, because that answer feeds directly into the project cost model. In this case the exposure is [fee structure and range]. If termination costs X and the Meraki deployment saves Y per month in operational costs, the math might favor paying the fee and proceeding. If termination costs far more than the savings, you wait. Either way you decide with numbers instead of assumptions.
Second, I researched the vendor as a company. That is how I found the acquisition. I wanted to know who I was actually dealing with before I called the number on the contract to introduce myself as the new CIO.
Third, I updated the infrastructure roadmap. The Meraki deployment now carries an explicit constraint: the SIP contract expires on its term date, review before commit. Anyone who opens the project plan sees it. The next person who picks up this project will not be surprised.
Building the Telecom Contract Calendar
After the discovery I audited every telecom-adjacent contract in the vendor registry. That included SIP trunking, POTS replacement lines, internet service agreements, managed MPLS, cellular fleet plans, and anything else with a term and an early termination clause.
The output was a telecom contract calendar with four columns: vendor, service type, expiration date, and infrastructure dependency. That last column matters most. For every contract I documented which infrastructure projects depend on the service and are therefore constrained by the term.
The calendar now lives in the same shared repository as the vendor registry. Hugo, my monitoring minion, watches it. Ninety days before any expiration, an alert surfaces and starts a documented review: assess the service, check the roadmap for dependencies, and decide between renewal and migration with enough lead time to execute either one cleanly.
That process did not exist before. It exists now because one contract in a folder called “Telecom Misc” was gating a six-figure infrastructure project.
What to Check Before You Plan Anything
If you are building a roadmap at an organization where the previous IT leadership did not maintain clean documentation, this is the sequence I now run before any project goes on the plan.
- Pull the full vendor registry and flag every vendor in the network, telecom, and connectivity categories.
- For each flagged vendor, locate the current executed agreement and extract the term end date and the early termination clause.
- Map each vendor against the projects on your roadmap. Would changes to this service affect, or be affected by, the planned work?
- For every vendor where the answer is yes, add an explicit constraint to the project plan with the contract date and the decision point.
- Research the vendor’s current ownership and corporate structure. Acquisitions change support models, escalation paths, and renewal dynamics.
This takes time up front. It takes far less time than discovering a blocking constraint six weeks into a project, after the equipment is ordered and the change windows are scheduled.
The Decision Ahead
The contract will run to its term date. Between now and then I will decide whether to migrate voice services to a different provider or renew with the parent company. I will make that call with complete information, enough lead time, and a clear picture of how it affects the Meraki timeline. That is not a guarantee of a good outcome. It is a guarantee that I will not be surprised.
In infrastructure planning, not being surprised is most of the job.
If you are doing telecom contract forensics at a new organization for the first time, do not build a contract list. Build a dependency map. Contracts are the starting point, but the question that matters is what you cannot do until each one expires. Once you can answer that for every active agreement, you can plan around it. Until then, you are planning blind. Pull your vendor registry this week and see what your own “Telecom Misc” folder is hiding.