Temporary infrastructure is interim capacity, such as rented equipment, colocation burst space, modular units, or cloud, that bridges a capacity gap while a months-long migration keeps origin and destination both running. The destination is not finished, the origin cannot be released, and somewhere in that overlap is a gap neither site can absorb.
Temporary infrastructure fills that gap. It is also the part of a migration program most likely to outlive its purpose, because nothing forces its removal once the crisis it solved has passed.
When Is Interim Capacity Warranted?
When the timing of the two sites leaves a known window that neither can cover, most often in these cases:
- Phased migrations where origin capacity must shrink before destination capacity is ready
- Destination construction or commissioning delays that arrive after equipment has been ordered
- Facility loss or damage requiring immediate capacity while a permanent plan is developed
- Capacity shortfalls during a refresh, where old equipment leaves before new equipment lands
- Testing and staging environments that need to exist alongside production during cutover
The common thread is a timing mismatch rather than a capacity shortage. That distinction matters, because it means the correct solution is the cheapest thing that closes a known window — not the best long-term architecture.
What Are the Options for Temporary Capacity?
Four, each suited to a different gap.
Rented equipment in existing space is the simplest when the origin or destination has floor space, power, and cooling to spare. Short lead times, no facility work, and the equipment leaves when the contract ends.
Colocation burst space suits organizations that need capacity in a different location or lack floor space entirely. Provider lead times for small footprints are usually weeks, and contract minimums often exceed the actual need.
Modular or containerized units solve the case where no suitable space exists at all. They are self-contained, deployable to a prepared pad, and genuinely fast once sited — but siting is the hard part.
Cloud capacity, in the NIST SP 800-145 sense of on-demand, elastic resources, works for workloads that are portable and tolerant of the move, and poorly for anything with hardware dependencies, licensing tied to physical characteristics, or latency coupling to systems that stay put.
Siting a Modular Unit
Containerized capacity is often presented as a drop-in answer. The unit itself is straightforward; everything around it is not.
- A prepared, level pad rated for the loaded weight
- Crane or heavy-transport access, including approach path and overhead clearance
- Local permitting, which varies enormously by jurisdiction and can dominate the timeline
- A power feed of adequate capacity, installed to NFPA 70 by a licensed electrician, plus generator and transfer switching if resilience is required
- Heat rejection — dry cooler placement, or a connection to a facility loop
- A fiber path back to the main facility, ordered early
- Physical security, since the unit sits outside the building envelope
Permitting and the power feed are the two items that turn a four-week deployment into a four-month one. Start both before the equipment order.
Why Is the Network the Hard Part?
Temporary capacity is only useful if it behaves like part of the existing environment.
- Extending the relevant network segments without creating a fragile stretched topology
- Latency between temporary and permanent capacity, measured against what the applications actually tolerate
- Firewall and security zoning, per your IT team's firewall policy, that treats the interim site as production, not as a lab
- Carrier circuits and cross-connects, which carry lead times unaffected by project urgency
- DNS, routing, and load balancer configuration that can be reversed cleanly later
Order connectivity the day the temporary site is confirmed. Circuit lead times are the most common reason interim capacity sits idle after it arrives.
Licensing, Support, and Insurance
Running two environments concurrently has commercial consequences that surface as invoices rather than outages.
- Software licensed per socket, core, or instance may require additional entitlement during the overlap
- Support contracts reference installation addresses that no longer match reality
- Rented equipment carries the vendor's warranty terms, not yours
- Insurance coverage for equipment outside the primary facility is worth confirming rather than assuming
Raise these at contracting time. Retroactive licensing conversations are expensive.
Design for Removal From Day One
Temporary infrastructure becomes permanent through inattention, not decision. Nothing about a working system generates pressure to dismantle it.
Write the exit into the plan at the start:
- Explicit removal criteria — what condition must be true for this to come out
- A target decommission date on the program schedule, with an owner
- A named budget holder responsible for the ongoing cost, so it stays visible
- The removal method and cost, estimated at procurement rather than discovered later
- A scheduled review if the date passes without removal
The budget owner matters most. Interim capacity that has no one accountable for its monthly cost is capacity that quietly becomes part of the estate.
Operational Integration
Interim does not mean unmanaged. Anything carrying production workload needs production operations from your IT team:
- Monitoring and alerting, routed to the same on-call rotation
- Data protection coverage, verified rather than assumed
- Patching and vulnerability management on the normal cycle
- Runbooks and documentation, including the fact that it exists and why
- Asset records reflecting the temporary state and its intended end date
The failure mode here is an environment nobody owns operationally because everyone regards it as short-lived. Short-lived systems still get compromised, still fill their disks, and still lose data.
Validate Before You Depend On It
Before workload moves in, test it as though it were permanent: capacity under real load, failover behavior, data restore, monitoring coverage, and access paths for the people who will support it.
Interim capacity is frequently commissioned under schedule pressure and validated less thoroughly than a permanent build. That is precisely backwards. It is carrying production workload during the period when the rest of the environment is least stable, which makes it the least appropriate place to accept unproven infrastructure.