Cloud Adoption for Utilities: How to Capitalize Migration Costs and Maintain Security

Over the last few years, utility companies have increasingly embraced digital transformation to improve the reliability and safety of electric services while meeting elevated consumer expectations and regulatory requirements. Though the pace has been gradual at times, we're seeing utility CIOs increasingly turn to cloud operating models to rise above historical industry constraints, seeking benefits like operational efficiencies, cost savings, scalability, agility and a clearer path to sustainability.

The embrace of cloud delivery models such as Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS) signals a seismic shift in the underlying role that on-premises IT infrastructure is poised to play in the industry.

The sector's pivot to cloud-based infrastructure, even if it has taken longer than other industries to materialize, raises some questions about just how utilities plan to navigate this change from a fiscal perspective.

While every situation is unique, and applicable regulations vary from state to state, this article outlines factors we think utilities should consider when weighing the pros and cons of pursuing cloud adoption, including tips on how to capitalize migration costs while maintaining a strong cybersecurity posture throughout the journey.

Strategies for capitalizing cloud costs and spend

Though regulatory and accounting frameworks have not yet been updated to achieve parity between the treatment of cloud-related costs and on-premises infrastructure investments, utilities can still find creative ways to minimize the potential financial ramifications of cloud migration. In fact, existing statutes give utilities options for capitalizing certain cloud-related costs. Here are some useful strategies to consider.

Capitalizing dedicated leased assets

One strategy for capitalizing cloud costs involves "qualified leased assets," which can usually be categorized as capital expenditures according to relevant accounting standards. In the cloud, such leased assets may include computing resources (e.g., virtual machines or storage space) rented from a public cloud hyperscaler (e.g., AWS, Google Cloud, Azure) for a length of time typically greater than 12 months.

The chart below details some of the basic definitions and qualifications to keep in mind about leased assets.

With the above criteria in mind, let's review several types of leased assets: sole-tenant nodes, dedicated hosts, dedicated instances and self-hosting.

Leased asset types: Sole-tenant nodes, dedicated hosts and dedicated instances

When engaging with a cloud hyperscaler like AWS, Google Cloud or Azure, you can often choose how your virtual machines (VMs) work on compute engines. With capitalization in mind, the key distinction comes down to running compute on shared versus dedicated nodes. Note: Although hyperscalers often use different terminology, the fundamental concepts below remain consistent across public cloud platforms.

Multi-tenant nodes: VMs running on multi-tenant nodes share a common pool of computing resources with multiple customers (i.e., tenants). Such resources include servers, storage and network infrastructure. (Generally not applicable to capitalization conversations.)
Sole-tenant nodes: VMs running on sole-tenant nodes are exclusively assigned to single accounts, meaning a specific set of computing resources is reserved for one organization's use. (Applicable to capitalization conversations.)
Dedicated hosts and dedicated instances:
- Like sole-tenant nodes, VMs running on dedicated hosts offer full hardware isolation via a dedicated single server. Dedicated instances run on hardware that is dedicated to a single hyperscaler account. There are key differences between dedicated hosts and instances, so make sure you understand the details before choosing an option. (Both are applicable to capitalization conversations.)

The diagram below highlights the differences between a normal host and a sole-tenant node set up.

Because you exercise total authority over your dedicated hardware, relevant regulatory and accounting standards may allow utilities to qualify such leased assets for capitalization purposes. Of course, utilities will first want to validate that the location of their VMs — whether running on multi-tenant or dedicated nodes — has been strategically selected for optimal functionality based on the specific applications and workloads they want to migrate.

Many products can run on sole-tenant nodes. Here is a non-exhaustive snapshot of such products, broken out by leading hyperscaler:

Google Cloud products: Google Compute Engine, Google Kubernetes Services (GKS), Google App Engine, Cloud SQL (MySQL, PostgreSQL, SQL Server), Cloud Spanner, Memorystore (Redis), Filestore, Google Cloud Storage, Transfer Appliance, Private Catalog, Google Kubernetes Private Cluster, Cloud Data Fusion, Cloud Composer, Cloud Dataflow, Anthos, BigQuery and Dataproc. Visit Google for more info.
AWS products: Amazon Elastic Compute Cloud (EC2), Amazon Elastic Kubernetes Services (EKS), Amazon Relational Database Service (RDS), Amazon Elastic Block Store (EBS), Amazon Elastic File System (EFS), Amazon Simple Storage Service (S3), AWS Batch, AWS Elastic Beanstalk, AWS Lambda, Amazon Virtual Private Cloud (VPC), AWS Certificate Manager, AWS CloudFormation, AWS Direct Connect, AWS Elastic Load Balancing (ELB), AWS Global Accelerator and AWS Outposts. Visit AWS for more info.
Azure products: Azure Virtual Machines, Azure Kubernetes Services (AKS), Azure Database for MySQL, Azure Database for PostgreSQL, Azure Database for MariaDB, Azure Backup Server, Azure Site Recovery, Azure Active Directory Domain Services, Azure Bastion, Azure Firewall, Azure ExpressRoute, Azure Application Gateway, Azure Load Balancer, Azure Front Door, Azure VPN Gateway, Azure Content Delivery Network (CDN) and Azure Stack. Visit Azure for more info. Visit Azure for more info.

Leased asset type: Self-hosting

Like dedicated hosts, dedicated instances and sole-tenant nodes, self-hosting might also qualify as a leased asset for capitalization purposes. However, unlike the other options, self-hosting involves managing the cloud infrastructure yourself. Whereas the isolated infrastructure offered by dedicated asset models is managed by your public cloud hyperscaler, self-hosting gives you full control over the infrastructure, including the operating system, applications and security configurations.

Additionally, virtual private servers (VPSs) — a type of self-hosted infrastructure — act like physical servers in so much as the VMs run atop physical servers provided by the hyperscaler. VPSs may also qualify as leased assets.

It's important to note that there are many other types of self-hosted infrastructures that may qualify as leased assets. Depending on the type of cloud operating model you plan to adopt, especially if you're pursuing a hybrid or private cloud model, you may be able to capitalize specific cloud products that can be moved on-premises.

Capitalizing cloud implementation and software development costs

Another strategy utilities should explore involves capitalizing the implementation and special software development costs related to cloud migration.

Implementation costs are expenses the utility incurs when executing or installing a cloud solution. These can be divided into two categories: software assets and service contracts.

Software assets include the costs incurred to acquire and install software licenses and related infrastructure, while service contracts encompass expenses paid to a hyperscaler to deliver a specific service. The difference is that software assets are generally capitalized and amortized over the term of the asset's useful life, while service contracts are normally expensed as incurred.

Qualifying cloud implementation costs under the accounting standard ASC 350-40 may include internal application development, application rationalization and refactoring, data migration, developer testing, etc., as long as those costs were incurred in connection with the acquisition or development of an asset.

The phase of your development project will dictate which costs can be capitalized. Accordingly, the capitalization window for this type of work will close once cloud migration is complete and the software or hosted environment is finalized. This typically occurs after the completion of all testing.

There are many useful guides out there for navigating the complexities of this specific subject.

Internally developed software

Utilities can also capitalize qualified development activities and the associated labor costs of their in-house software developers, as priced into the cost basis of the software. For example, qualified activities would likely include a developer who trains a machine learning model on data sets ingested from their public cloud hyperscaler. This also touches on the concept of intellectual property (IP) and what goes into the generation of IP. Such costs may also qualify for capitalization under existing regulations.

Cloud marketplace procurement and enterprise license agreements

Cloud marketplaces — like AWS Marketplace, Google Marketplace and Azure Marketplace — offer utilities an alternative for capitalizing cloud software costs. These emerging online marketplaces offer comprehensive catalogs of on-demand software solutions and professional services from thousands of independent software vendors (ISVs), cloud service providers and channel partners.

Software licenses acquired through cloud marketplaces can often be categorized as qualified leased assets on a utility's balance sheet. If the software lease meets the definition of a finance lease (i.e., a lease that transfers substantially all risks and rewards of ownership to the lessee), then the utility can recognize the leased asset on its balance sheet and depreciate the third-party software from the cloud marketplace over its useful life.

Similarly, utilities that sign up for an enterprise discount program with a hyperscaler should explore ways to capitalize these costs. These savings programs offer volume discounts when a customer commits to a higher annual cloud spend, a longer contract timeframe, or both. The standard length of enterprise discount programs potentially qualifies them as leased assets depending on the specific term and conditions of the prepayment plan and the applicable accounting guidelines.

Ultimately, utilities are advised to consult with their internal account teams to determine whether their discount program with a hyperscaler can be classified as a capitalizable leased asset under ASC 842, IFRS-16, ASC 350-40 and ASC 360-10 accounting standards.

Below are a few examples of recent cloud migration success stories in which utilities were able to successfully include leased assets in their rate base for earnings purposes:

Leased cloud infrastructure for data storage and processing: In 2018, E.ON signed a multi-year agreement with AWS to lease cloud infrastructure for its digital transformation.
Leased cloud application for customer service: In 2019, Consolidated Edison signed a contract with Salesforce to lease its cloud-based customer service platform.
Leased cloud security services for threat detection and response: In 2020, the New York Power Authority signed a contract with IBM to strengthen its cybersecurity capabilities.

Strategies for mitigating cloud security risks

Cloud security is a critical aspect of cloud migration that all organizations must consider, regardless of industry. For utility companies, the sensitive nature of operations and the potential consequences of security breaches make migration a tricky process to navigate.

With the possibility of exposing confidential customer data or compromising critical infrastructure, it's understandable why utilities might feel a bit more hesitant than those in other industries to embrace cloud migration. However, with proper cloud security measures in place, utilities can move one step closer to realizing the many benefits of cloud while minimizing security risks.

To establish a robust cloud security posture, we recommend utilities adopt a multi-layered approach that includes both preventative and detective measures. Preventative measures (e.g., identity and access management, data encryption and networking segmentation) can prevent unauthorized access and protect data confidentiality. Detective measures (e.g., intrusion detection and security event monitoring) can help utilities detect and respond to potential threats faster.

Additionally, aligning cloud security strategies with industry standards and regulations such as the CIS Controls, C2MC, CMMC, and NIST Cybersecurity Frameworks are crucial to establishing a robust cloud security posture. These frameworks provide a comprehensive set of security controls and practices utilities can use to develop and implement a resilient security program.

It should be emphasized that the cybersecurity frameworks mentioned above might not be appropriate for certain data or systems given the risk of data breaches and unauthorized access. Some utilities, such as nuclear power plants or water treatment facilities, may be required to maintain critical infrastructure on-premises due to concerns surrounding data security controls, system risks, etc.

Here are some resources to get you started on understanding how each respective cloud hyperscaler moves systems and data with these cybersecurity frameworks in mind:

As you're exploring your cloud migration and security options, we recommended prioritizing "shift left" solutions that evaluate security policies early on in the software development lifecycle.

Conclusion

Despite the challenges, migration to the cloud remains a major opportunity for utilities. By analyzing which migration costs can be capitalized under existing regulations, utilities can minimize potential impacts on their bottom line. And by adopting robust cloud security measures and collaborating with hyperscalers to implement best practices and safeguards, utilities can mitigate the risks and position themselves to fully realize the many benefits of cloud computing.

When it comes to measuring your cloud migration progress, it's important to recognize that every migration is unique and may require tailored solutions not applicable to others. Some important systems may be too high risk or impact the utility charter to move to the cloud. Our utility, cloud and cybersecurity experts are all available to answer any questions you might have as you navigate this complex-yet-exciting journey.