If you run a colocation facility, you already know the pain. Your DCIM tool tracks assets. Your BMS watches cooling. Your EPMS handles power. Your billing lives in a spreadsheet. None of these systems talk to each other, and you are the integration layer. This is the status quo for most colo operators, and it has been for over a decade.
DCIM was never built for colos
The major DCIM platforms on the market today were designed for a specific customer: large enterprises managing their own data centers. Think banks, insurance companies, and government agencies with thousands of servers they own and operate themselves. The core job was asset management. Where is server X? What rack is it in? When does the warranty expire?
Nlyte started as an asset and capacity planning tool for enterprise IT departments. Sunbird (dcTrack) was built around the same idea: model your racks, track your ports, manage your cabling. Schneider's EcoStruxure IT grew out of their existing building management and UPS monitoring stack and bolted on DCIM features over time. None of them were built for how data centers operate today.
But colocation is a different business. Managing assets is a small part of the job. You sell power and space to tenants who bring their own equipment. You need to meter every circuit, bill accurately every month, keep cooling within SLA, and do it all with a lean operations team running 24/7. The enterprise DCIM vendors never prioritized these workflows because their paying customers didn't need them.
The real problems colo operators face
Talk to anyone running operations at a 5 to 50 MW colocation facility, and you will hear the same set of frustrations over and over:
Billing that still runs on spreadsheets
Power billing is the core revenue model for most colos, yet the billing process itself is often manual. Someone pulls meter reads from the EPMS, copies them into a spreadsheet, applies rate structures, and generates invoices. This happens every month, and it is error-prone. Disputes eat up staff time, and when a customer asks for a breakdown of their power usage by circuit, the answer is usually "give us a few days."
Three vendors for one building
A typical colo might have a BMS from Siemens or Honeywell for cooling and environmental monitoring, power metering from Schneider or Eaton, and a DCIM tool from Nlyte or Sunbird for asset tracking. Each system has its own interface, its own alerting, its own data model. When something goes wrong at 2 AM, the on-call engineer has to check three different dashboards to piece together what is happening. That is not a workflow. That is a scavenger hunt.
Deployments that take months
Traditional DCIM deployments are projects, not products. You sign a contract, then spend weeks in discovery. Then weeks modeling your facility. Then weeks training your staff. Professional services bills stack up. Six months later, you have a system that mostly works if someone remembers to keep it updated. This is why so many DCIM deployments end up as expensive shelfware.
Manual device onboarding
Every time a new customer deploys equipment, someone has to manually enter assets into the DCIM. Rack location, power connections, network ports, customer assignment. In a busy colo doing multiple deployments a week, this data entry backlog means the DCIM is always out of date. And an out-of-date DCIM is worse than no DCIM at all, because people stop trusting it.
What the enterprise vendors got wrong
Nlyte, Sunbird, and Schneider built software for enterprise IT departments, not for data center operators. The mismatch shows up in specific ways:
- No native power billing. Enterprise data centers don't bill tenants for power, so DCIM vendors never built billing workflows. Colo operators have to export data and handle billing externally.
- Cooling and power in separate tools. In an enterprise data center, the facilities team handles HVAC and the IT team handles servers. Different people, different tools. In a colo, the same ops team manages both, and they need one view.
- Tenant isolation is an afterthought. Enterprise DCIM assumes one organization owns everything. Multi-tenancy, customer portals, and per-tenant reporting were never part of the original design.
- Pricing based on rack count or sensor count. This penalizes dense colo environments and makes costs unpredictable as you grow.
- On-premise first. Many legacy platforms still need local servers and a database, and your already-stretched team ends up running them.
What colocation operators actually need
After years of talking to colo operators, we hear the same wish list every time:
- Integrated power metering and billing: Pull meter data automatically, apply rate structures, generate invoices, and let customers see their own usage. All in one place.
- Cooling and environmental monitoring: Temperature, humidity, and airflow shown next to power data, rather than in a separate BMS the ops team has to alt-tab into.
- Alerting that works at 2 AM: One alerting system that covers power, cooling, and capacity, with escalation paths that match how your NOC runs, instead of three alert streams from three vendors.
- Fast deployment: Days or weeks, not months. Connect the meters, map the infrastructure, and start using it. Professional services should be optional, not mandatory.
- Device discovery that reduces manual work: Scan the network, identify what is connected, and pre-populate asset records. The goal is not zero manual entry, but a lot less of it.
- Tenant-aware from the start: Every feature should understand that you have multiple customers sharing infrastructure. Per-tenant dashboards, per-tenant billing, per-tenant SLA tracking.
Why this hasn't changed until now
The colo market was not large enough to attract dedicated software development. Enterprise IT departments were the big spenders, so vendors built for them. Colo operators made do with a patchwork of tools because there was nothing better.
That is changing. The colocation market is much bigger now, and operators are looking for software that fits how they work. The incumbents are retrofitting multi-tenant features onto enterprise architectures, and that approach has limits. Building for colo from the start produces a different product.
The path forward
If you are evaluating DCIM platforms for a colocation facility, ask vendors direct questions. Can I generate a tenant power bill from this system without exporting to a spreadsheet? Can I see power and cooling on the same dashboard? How long does deployment take, and what does it cost? Can my customers log in and see their own data?
If the answer involves "professional services engagement" or "we can customize that," you are looking at the wrong tool. These should be standard features, not custom projects.
Aravolta was built from day one for colocation operators. Power metering, billing, cooling monitoring, and operations in a single platform. We did not start with an enterprise asset tracker and try to bolt on colo features. We started with the problems colo teams deal with every day and built the software around those.
Frequently asked questions
Why don't traditional DCIM platforms support power billing?
Traditional DCIM platforms like Nlyte and Sunbird were built for enterprise IT departments that own their whole infrastructure. There are no tenants to bill in that model, so billing was never built as a native feature. Colo operators who need it export meter data and run invoices in a separate system.
Why do colo operators end up with three or more separate monitoring systems?
Because the market grew up in silos. BMS vendors like Siemens and Honeywell handle HVAC and environmental controls. EPMS vendors like Schneider and Eaton handle power distribution and metering. DCIM vendors handle asset tracking and capacity planning. No single vendor covered all three well enough for colo operations, so operators stitch the tools together with manual processes as the glue.
How long does a typical DCIM deployment take?
For legacy DCIM platforms, a full deployment (discovery, facility modeling, integration, and training) commonly takes three to six months, and complex ones run longer. Most of that time goes to professional services, custom configuration, and modeling every asset and connection in the facility before the system is useful.
What should I ask a DCIM vendor during an evaluation?
Ask about your daily workflows. Can the system generate tenant power bills without a spreadsheet export? Does it show power and cooling on the same dashboard? How does alerting work across power and environmental events? Can tenants log in and see their own usage? How long does deployment take, and are professional services required or optional? The answers separate tools built for colos from enterprise tools with colo features bolted on.
Can I replace my BMS and EPMS with a DCIM platform?
Yes. Aravolta includes native BMS and EPMS functions. It connects directly to your chillers, CRACs, sensors, PDUs, and breaker panels over BACnet, Modbus, and SNMP, so you do not need a separate BMS or EPMS vendor. Your operations team gets one platform for power metering, cooling monitoring, asset management, and tenant billing.
Why does my DCIM data end up out of date?
In most colos, keeping a DCIM current means manual data entry every time a customer deploys, moves, or removes equipment. With several deployments a week, the backlog grows. Once staff stop trusting the data, they stop using the system, and the data gets staler still. The way out is cutting the manual work needed to keep records current.
What makes Aravolta different from Nlyte, Sunbird, or EcoStruxure?
Aravolta was built for colocation operators, not retrofitted from an enterprise asset management tool. Power metering, tenant billing, cooling monitoring, and 24/7 operations workflows are core features. Deployment takes days rather than months, and the platform is multi-tenant from the ground up, so per-customer dashboards, billing, and SLA tracking are built in instead of customized on top.
Last updated: March 2026