Technology Integration for Energy & Utilities in Dallas, TX
Oncor is the largest transmission and distribution utility in Texas and one of the largest in the country, and the integration realities inside a Dallas-area utility reflect that scale. Somewhere in the stack there's a CIS that's been modernized once and is due again, an OMS that survived the February 2021 event but needed serious patching afterward, an AMI footprint approaching full deployment, a GIS that's been on a multi-year Esri Utility Network journey, and a middleware layer that's a mix of strategic iPaaS investment and tactical integrations written by contractors years ago. Sitting on top of that is ERCOT — the 814, 650, and 867 transaction flows connecting Oncor's TDU systems to hundreds of REPs, the wholesale market interfaces, and the reliability reporting cadence that got more intense after Uri and hasn't relaxed since. Integration in Dallas isn't just about making the boxes talk — it's about making the utility defensible at rate case, survivable during a major event, and extensible as DER, EV charging load, and data center demand reshape the North Texas grid faster than the architecture diagrams can keep up. MSG builds integrations that hold through all of it.
Oncor is the largest transmission and distribution utility in Texas and one of the largest in the country, and the integration realities inside a Dallas-area utility reflect that scale.
Dallas
The Dallas metro is ~7.9 million people across North Texas, with Oncor serving roughly 3.9 million premises as the TDU across most of the region. Dallas proper is ~1.3 million, Fort Worth adjacent adds another million, and the collar — Plano, Frisco, McKinney, Arlington, Irving, Garland, Grand Prairie — carries the explosive suburban growth that's been reshaping Oncor's distribution planning for a decade. Dallas is also a generation and retail hub: Vistra Corp is headquartered in Irving with its Luminant generation fleet across Texas, TXU Energy and other major REPs operate from the metro, and ERCOT's own headquarters is in Taylor but with significant operational presence reaching into the DFW area.
The data center boom is the integration story of the last three years. North Texas has become one of the biggest data center markets in the country, with new loads that dwarf anything Oncor planned for in the 2010s. Every new hyperscale interconnect creates integration requirements: the CIS has to handle a customer with tens or hundreds of megawatts of load, the ADMS has to model the feeders supporting them, the asset management system has to track the substation buildouts, and the reliability reporting has to account for customers whose operational expectations are different from a residential ratepayer's. Data center load is pushing through the integration layer in ways that weren't in most Texas utilities' 2015 architectures.
Post-Uri regulatory scrutiny remains intense. PUCT, ERCOT, and the Texas Legislature keep the reliability conversation active, and every Oncor rate case, every major storm response review, and every resilience filing turns on data that flows through the integration layer. If the data can't be produced cleanly, the utility takes a regulatory hit. MSG is 302 miles east of downtown Dallas on I-20/I-10 — about five hours. For Dallas engagements we structure around multi-day onsite immersions with weekly video between, and we commit to onsite presence through any major event window during the engagement.
Delivery
An Oncor-scale or major REP-scale integration engagement starts with an audit that takes the actual state of the integration layer as the starting point, not the aspirational architecture. We map CIS (Oracle CC&B or Customer1, SAP IS-U in some peers), OMS, ADMS, the AMI headend (Landis+Gyr and Itron both have footprint), the GIS and asset management stack, the ERCOT-facing integration layer, and the middleware underneath. We read the transaction flows end-to-end — an 814 move-in, an 867 usage exchange, an outage event from last-gasp through crew dispatch to restoration. We interview the storm desk and the rate case team about what data they can't get cleanly today.
From the audit we produce an architecture that's honest about IT-OT, NERC CIP scoping, ERCOT connectivity, and the DER and EV load integration work that's coming whether or not current systems are ready. Implementation uses what you have where it works: MuleSoft, Informatica, Boomi, a Kafka backbone, or a hybrid. We replace only the patterns that are failing or that can't scale to the new load profile. For Dallas-scale engagements we typically scope in phases: initial audit and architecture (10-14 weeks), first high-priority integration build (16-24 weeks), broader roadmap rollout over 12-18 months with explicit cutover rehearsals before any major go-live.
Energy & Utilities
The Texas TDU integration model is structurally different from a vertically integrated utility and worth understanding on its own terms. The customer relationship is split between the TDU (who owns the meter and the wires) and the REP (who owns the billing and the commercial relationship), with ERCOT as the intermediary for the transaction flows that connect them. That split pushes integration complexity into specific places — the 814, 650, and 867 flows in particular carry most of the operational data exchange, and every one of those flows is a place where integration failures produce regulatory exposure and customer experience damage.
Outage management is where Texas TDUs are judged publicly, and the integration layer supporting OMS is carrying more load than the vendor originally designed for. A modern outage lifecycle in Dallas-scale operations fuses AMI last-gasp signals, customer call data from the CIS-adjacent contact center, social media and outage-map traffic from the customer portal, crew position data from mobile workforce management, and GIS topology — and then produces ETRs, public-facing outage map updates, reliability metrics, and regulatory reports. Every broken link in that chain costs SAIDI/SAIFI points and costs customer trust. Integration work that upgrades the OMS feed patterns typically pays back faster than almost any other integration investment.
DER integration is no longer theoretical in North Texas. Rooftop solar is scaling, battery storage is showing up on feeders, EV charging loads are clustering at commercial sites, and ERCOT is rolling out DER market participation frameworks that will require data flows no one built five years ago. The utilities that are investing in the DERMS-to-CIS-to-AMI-to-GIS integration layer now are positioning to operate this shift. The ones that are waiting for vendor-shipped turnkey solutions will find themselves two years behind when the load shows up.
MSG
MSG ships production software. ServiceStorm is a multi-tenant SaaS platform running for home services operators — we operate it, integrate it with third-party ecosystems, and carry the SLA responsibility for real customers every day. MFGBase is a B2B manufacturer marketplace in production. LocalAISource is a production AI professionals directory. Every one of those products has live integration surface that has to actually work, and the engineering discipline that requires shows up in how we run utility engagements.
We don't hand off a slide deck. We write adapters, build observability, stand in the NOC during storm events, and scope engagements to end at a system your team runs without us. We work with whatever integration platform you have — MuleSoft, Boomi, Informatica, native iPaaS, Kafka — rather than arriving with a product to sell you. Every architecture decision is defensible at audit and in public.
Beaumont to Dallas is five hours on the ground. We structure Dallas engagements around concentrated onsite immersions — typically four-day weeks during active implementation phases, weekly onsite during steady-state work, and onsite through any major storm or cutover. We're close enough to treat Dallas as a home market and far enough to stay sharp on our travel and documentation discipline.
Twelve months in, a Dallas TDU or major REP has an integration layer that survives storm-scale load, carries clean ERCOT transaction flows without manual exception handling, produces reliability data that passes audit without rework, and supports DER and data center interconnect workflows without custom builds every time. OMS holds context through major events. CIS-to-REP data exchange is auditable. Rate case data pulls cleanly from operational systems. Your own integration team extends the platform without vendor dependency.
Things operators ask
The 814, 650, and 867 ERCOT transaction flows are a constant source of exception handling pain. Can integration work actually fix that?
Yes, and it's one of the higher-ROI areas in Texas TDU integration. The pain is usually not the ERCOT transaction format itself — that's well-documented and stable — it's the layers of custom mapping, validation, and exception handling that have been bolted on over years as edge cases showed up. We audit the actual exception patterns: which transaction subtypes are producing the most manual intervention, which REPs are generating the most rejections, which move-in and move-out scenarios are breaking the current logic. From there we redesign the ERCOT-facing integration with cleaner validation upstream (catching bad data before it hits the transaction layer), better exception classification (routing to the right team automatically rather than dumping everything into a single queue), and documented business rule logic that can be maintained without tribal knowledge. Most utilities we've seen cut manual exception handling by 50-70% with a targeted 12-16 week engagement focused specifically on ERCOT flow hygiene.
Our OMS got hammered during the last major event and we're under pressure to modernize. Full replacement or integration-first?
Integration-first almost always, and then revisit replacement when the integration story is clean. OMS replacement is a 2-4 year program with significant risk, and most utilities that start with 'replace the OMS' end up discovering that 60-70% of their operational pain was actually in the integration layer around the OMS — the AMI feed, the CIS customer context, the crew dispatch handoff, the outage map publishing. Fixing those integration layers delivers most of the operational improvement at a fraction of the cost and timeline, and if you still need to replace the OMS afterward, you're doing it with a clean integration layer that makes the replacement much less risky. We'd start by reconstructing what actually failed during the last major event at the integration layer, identifying specific choke points and storm-mode patterns that need rebuilding, and scoping a phased improvement that gets the most leverage soonest.
How do you handle the NERC CIP compliance implications of integration work?
Explicitly and from day one. Every integration design we produce includes a CIP scoping document identifying which components are inside the electronic security perimeter, which are outside, and what compensating controls apply at every boundary crossing. CIP-005 (electronic security perimeter), CIP-007 (systems security management), CIP-010 (configuration and change management) are designed into the architecture, not retrofitted for audit. Where data has to cross the ESP, we use data diode or one-way transfer patterns where appropriate, documented API gateways with change-controlled whitelists where bidirectional flow is required, and logging that gives your compliance team the audit trail they need. We also coordinate with your CIP compliance lead throughout the engagement so there are no surprises when internal audit or the external auditor walks through. CIP audit findings during an active project create the kind of scope chaos that sinks timelines, and they're avoidable with discipline in the first weeks. We also track change management artifacts as we go so there's no scramble at audit time to reconstruct who changed what and why.
Data center interconnects are creating huge new loads. How should we think about integration implications?
Data center customers break assumptions baked into utility systems that were designed for residential and small commercial load profiles. A single hyperscale site might have more megawatts than an entire small town's feeder. That changes what the CIS has to carry (large-customer billing, contract terms, interruptible program enrollment), what the ADMS has to model (dedicated substations, large customer load profiles, coordination with customer-side generation), what asset management has to track (substation buildouts with tight construction timelines), and what reliability reporting has to handle (data center customers have very different expectations and contract-backed SLAs). We'd map your specific data center interconnect workflow, identify where integration gaps are producing manual work or commitment risk, and build the integration patterns that let the utility handle 50 more data center interconnects over the next five years without linear headcount growth. This is a real bottleneck and most utilities don't see it as an integration problem until the backlog is serious.
We have a long-running iPaaS program with significant investment. Are you going to try to replace it?
No. Integration platforms are rarely the actual problem — patterns, governance, and observability usually are. We build on your existing iPaaS where we can, document the patterns clearly, and add observability and governance around the existing implementation. We only recommend platform changes if there's a concrete, measurable capability gap that can't be closed on the current platform — for example, the current platform is fundamentally batch-oriented and you need high-throughput event streaming for AMI-scale data. Even then, we'd implement the new capability alongside, validate it under real load, and migrate incrementally rather than swap in a big bang. Integration projects that start with 'replace the iPaaS' are the ones that fail most visibly. We don't do them. Platform-replacement consulting sells well because it's a big-ticket engagement with a story the sponsor can tell the CIO. It almost never survives contact with production. We'd rather deliver a smaller, working integration improvement that moves the operational needle than sell you a three-year platform migration that dies in year two.
How does MSG actually work with our existing systems integrators and vendors?
Collaboratively and with clear scope boundaries. Dallas-scale utilities and REPs typically have an incumbent SI or prime — Accenture, Deloitte, IBM, Capgemini, or a specialist like Burns & McDonnell or POWER Engineering — on major programs. We're usually scoped to handle a specific integration workstream the prime isn't focused on, or to audit and rebuild an integration layer that isn't performing in production. We coordinate with the prime, document interface contracts in writing, and keep the boundaries clean. Vendor relationships — Oracle, SAP, Schneider, GE, ABB, Itron, Landis+Gyr, Esri — we work through published integration interfaces, engage vendor professional services where appropriate, and document every deviation. We don't write custom code against undocumented internal APIs. When a vendor needs to be pushed on a real capability gap, we help the utility build a grounded business case rather than generic pressure. Most vendors respond constructively when the ask is specific.
Other Industries in Dallas
Tech Integration in Other Cities
Other MSG Services
Ready to harden your Dallas utility integration layer?
Let's audit the ERCOT flows, the storm-mode patterns, and the data center interconnect pipeline — then build integration that scales.