Cloud Migration Complexities
Background
Many organizations today are recognizing the benefits of cloud computing and
migrating their on-premise software footprint to the cloud. Depending on their
needs, organizations can engage with vendors for different types of cloud-based
arrangements, including, but not limited to, the following:
-
Software as a service (SaaS), which gives entities cloud-based Internet access to a wide range of applications managed by third-party vendors.
-
Platform as a service (PaaS), an arrangement in which a third-party vendor provides a framework (a “platform”) for a customer’s in-house software developers (or a mix of in-house and third-party developers) to create and manage one or more applications.
-
Infrastructure as a service (IaaS), a more comprehensive arrangement in which a third-party vendor delivers cloud computing infrastructure (including servers, a network, and storage) to a customer through a dashboard or visualization. The customer has complete control over the infrastructure, while the vendor is responsible for managing the servers, network, and storage.
Different approaches to determining how an organization will migrate its
applications to the cloud will affect the type and scale of costs incurred. For
example, rehosting (often referred to as “lift and shift”), which involves
redeploying existing applications and data (the “lift”) into a public cloud (the
“shift”) will most likely result in costs associated with data migration and
configuration of the hosting environment. Replatforming,1 which builds on rehosting, involves making changes to data and
applications to optimize performance in the cloud. Replatforming will most
likely involve incremental costs since additional changes are often made to
modify or enhance the functionality of the applications that are migrated to the
cloud. Other cloud migration approaches that require significant revisions of
existing architectures, such as full or partial rebuilds2 of existing code, may involve broader and more significant costs because
of the amount and potential complexity of coding necessary to develop the
desired functionality that the cloud environment enables.
Regardless of how an entity migrates applications to the cloud, the accounting
for the migration costs can be complex and may require additional processes and
controls. Many of the costs incurred will be within the scope of ASC 350-40.3 However, identifying the costs that should be expensed as incurred,
capitalized, or deferred can be challenging. It is imperative for management to
have a process in place for appropriately identifying and categorizing costs and
a strong understanding of the scope and recognition criteria in ASC 350-40 that
apply to cloud migrations.
Scope Considerations
The accounting framework used to account for costs incurred in connection with a
cloud migration is the same regardless of whether the cost associated with
implementing a hosting arrangement is for a service contract or for the
acquisition or development of internal-use software. However, entities that
undergo cloud migrations will still need to understand the nature of both the
underlying cost and the technology to which those cloud migrations are related
so that they can properly (1) identify the costs that should be deferred or
capitalized and (2) present the costs in the financial statements.
Differentiating Between a Service Contract and Internal-Use Software
As noted in paragraph BC2 of ASU 2018-15,4 hosting arrangements that are service contracts include SaaS, PaaS,
and IaaS. Accordingly, the implementation activities associated with these
arrangements will be within scope of the guidance in ASC 350-40 applicable
to hosting arrangements. This means that while eligible costs incurred
during the application development stage to implement SaaS, PaaS, or IaaS
may be deferred, they will ultimately be presented in the same financial
statement line item as that of the hosting fees (i.e., an operating
expense).
However, some hosting arrangements may include internal-use software. ASC
350-40-15-4A notes that software that is accessed through a hosting
arrangement is considered internal-use software if (1) the entity “has the
contractual right to take possession of the software at any time during the
hosting period without significant penalty” and (2) “[i]t is feasible for
the [entity] to either run the software on its own hardware or contract
with another party unrelated to the [software] vendor to host the
software” (emphasis added). Accordingly, software hosted by a third party
with whom the entity has contracted (i.e., a party other than the software
vendor) is considered internal-use software (rather than a hosting
arrangement that is a service contract). This is because the guidance
acknowledges that internal-use software can be hosted by a party unrelated
to the software vendor.
Costs incurred to implement SaaS, PaaS, or IaaS should be distinguished from
those incurred to develop or obtain internal-use software because the
capitalized costs are presented differently. On an entity’s balance sheet,
the deferred costs of implementing SaaS, PaaS, or IaaS are presented with
prepaid expenses rather than with software assets. Further, when such costs
are amortized, they are presented in an entity’s income statement as an
operating expense with the associated hosting fees rather than as
amortization expense. Entities will need to analyze the incurred costs
associated with migrating applications to the cloud to determine whether to
account for them as costs related to a service contract, an internal-use
software asset, or both since hybrid cloud migrations often involve both
internal-use software components and SaaS, PaaS, or IaaS components.
Example 1
Entity C is refactoring its enterprise resource
planning (ERP) system (an internal-use software
asset) to be hosted by Company X, a third-party
hosting provider. The parties enter into a contract
in which X promises to provide hosting (computing
capacity and storage) to C for a three-year period.
Entity C incurs $50,000 to configure the hosting
environment for its use and $100,000 to modify and
enhance the ERP system so that the system can be
migrated to X’s environment. Entity C concludes that
(1) the $50,000 incurred to configure the hosted
environment is within the scope of the guidance on
implementing a hosting arrangement that is a service
contract and (2) the $100,000 incurred to modify and
enhance the ERP system is within the scope of the
guidance on developing or obtaining internal-use
software.
Connecting the Dots
The guidance in ASC 350-40 must be applied at the individual
component or module level. While there is no specific guidance on
what an individual component or module might be, an entity could
consider the level of functionality that each component or module in
a hosted software arrangement provides as well as the level of
interdependence between the components or modules. Determining the
appropriate components or modules is important for (1) assessing
whether a component or module should be accounted for as a service
contract or internal-use software and (2) identifying which stage of
software development (as described below) an entity is in.
For additional discussion of scope considerations related to
software development arrangements, see Deloitte’s June 2020 Technology
Spotlight.
Identifying Capitalizable or Deferrable Costs
ASC 350-40 provides a consistent recognition framework for identifying
capitalizable costs regardless of whether an arrangement is a service contract
or internal-use software. Costs incurred during the preliminary project stage,
when entities are exploring different approaches and considering vendors to
execute their cloud migration, will be expensed as incurred.
The application development period commences once (1) management with the
relevant authority approves and commits funding for the project (to be
considered at the component or module level) and (2) it is probable that the
project will be completed and used as intended. During this period, certain
costs should be either deferred and presented with prepaid expenses (to the
extent that the costs are associated with implementing a hosting service
contract) or capitalized as a software asset (to the extent that the costs are
associated with acquiring, developing, upgrading, or enhancing internal-use
software). Those costs include external direct costs of materials and services
(e.g., purchase of software, fees paid to third-party developers or consultants)
and internal direct costs of materials and services (e.g., payroll costs and
other employee benefits of software developers, certain interest costs).
However, indirect overhead costs should be expensed as incurred. Capitalization
of development or implementation costs will cease once the application migration
is complete and the software, the hosted environment, or both are substantially
complete and ready for their intended use. This is typically after all testing
is completed.
Entities migrating their applications to the cloud may incur different costs
depending on the type of arrangement they enter into (SaaS, PaaS, or IaaS), the
approach to cloud migration (rehosting, replatforming, refactoring, rebuilding,
or replacing), and the mix of internal and external resources dedicated to the
migration. Management will need to determine whether the costs incurred qualify
for capitalization or deferral on the basis of the nature of the cost and the
stage of development. The guidance in ASC 350-40 does not provide separate
frameworks for the capitalization of internal costs (e.g., payroll, cost of
materials) and the capitalization of external costs (e.g., third-party service
providers), nor does it define “implementation costs.” In general, costs
directly related to obtaining software; developing, upgrading, or enhancing
software (e.g., coding and configuration); and testing will qualify for
capitalization or deferral. However, certain costs must be expensed as incurred:
-
Data conversion costs — While the costs associated with developing or obtaining software that allows for access or conversion of old data by new systems should be capitalized, costs of data conversion and data validation that are either performed manually or outsourced to a third party should generally be expensed as incurred. Entities that outsource data conversion activities may need to evaluate whether any costs incurred are related to obtaining internal-use data conversion software (even if the data conversion software is temporary); if so, such costs would be capitalized. All other data conversion costs must be expensed.
-
Training costs — Costs of training an organization’s employees should be expensed as incurred. These costs may be (1) internal or (2) external (since in many cloud migrations, such training is provided by the hosting provider or another third-party consultant). However, costs incurred to develop or obtain a training module within a cloud-based application can be considered for capitalization or deferral.
-
Maintenance costs — ASC 350-40 does not define maintenance; however, entities can look to the glossary of ASC 985-20, which defines the term as “[a]ctivities undertaken after the product is available for general release to customers to correct errors or keep the product updated with current information. Those activities include routine changes and additions.” Entities may find it challenging to differentiate maintenance costs that must be expensed as incurred from capitalizable costs of software upgrades and enhancements. To qualify for capitalization, upgrades and enhancements must provide additional functionality.
-
Business process reengineering costs — Costs of reengineering activities, which often are associated with new or upgraded software applications, are not within the scope of ASC 350-40; rather, they are within the scope of ASC 720-45. It is critical for entities to carefully track activities undertaken during cloud migration and software development since a cloud migration is a natural time for entities to reengineer or integrate business processes.
When migrating existing applications to the cloud, entities should carefully
evaluate whether upgrades or enhancements are made to each application that is
moving to the cloud. This is because only costs associated with upgrades and
enhancements that add new functionality can be capitalized.
Example 2
Entity T is migrating two of its existing applications
(Software X and Software Y) to a third-party hosted
environment. Software X will be rehosted with minimal
changes that do not add new functionality in the hosted
environment, while Software Y will be refactored with
significant changes to the coding that will add new
functionality to Software Y when that software goes live
in the hosted environment. Entity T concludes that the
costs incurred to modify Software X are not eligible for
capitalization because no new functionality is being
created. However, T also concludes that eligible costs
incurred during the application development stage to
modify Software Y should be capitalized since new
functionality is being developed as a result of the
cloud migration.
In addition to the costs listed above, any general and administrative costs must
also be expensed as incurred. Entities undergoing cloud migrations will need to
carefully analyze payroll and payroll-related costs to determine the amount of
costs that qualify for capitalization and the amount of costs that must be
expensed as incurred since certain employees may devote their time to various
activities across numerous projects in different phases of development.
Example 3
Company B is a large manufacturing entity that has scaled
up through acquisitions and now has global operations.
Accordingly, B decided to consolidate and move certain
inventory and purchasing applications to the cloud
through an IaaS arrangement. IT Supervisor 1 is
partially responsible for overseeing B’s implementation
of this arrangement. The cloud-based software will
contain the following applications, which are considered
separate modules: (1) Product Planning, (2) Materials
Purchasing, and (3) Inventory Management.
The Inventory Management application is in the
preliminary project stage, while Product Planning and
Materials Purchasing are in application development.
Using B’s current job cost tracking system, the
company’s accounting department determines that IT
Supervisor 1 is spending her time as follows:
-
Planning the design of the Inventory Management module: 20 percent.
-
Reviewing changes to coding, which provide additional functionality, for the Product Planning and Materials Purchasing modules: 50 percent.
-
Reviewing customized user training manuals: 20 percent.
-
Holding meetings with accounting department personnel to ensure that software development and business processes are integrated: 10 percent.
Company B determines that (1) only the time spent on
reviewing changes to code for the Product Planning and
Materials Purchasing modules qualifies for
capitalization and (2) the remainder of IT Supervisor
1’s payroll and payroll-related costs must be expensed
as incurred.
Similarly, entities undergoing cloud migrations will need to carefully analyze
third-party invoices to determine which costs must be deferred or capitalized.
Third-party service providers may provide some or all of the services required
to migrate applications to the cloud, including the third-party hosting
services. Entities may need to allocate third-party costs to the different
elements in the arrangement (e.g., configuration, training, hosting); such
allocation should be based on the relative stand-alone selling prices of the
elements in the contract and not necessarily on the elements’ respective prices
as stated in the contract.
Connecting the Dots
The accounting guidance clearly indicates that in an arrangement
accounted for as a service contract, the hosting fees should be expensed
unless paid in advance of the hosting period (e.g., a prepayment of an
annual fee for hosting services). However, upon determining that costs
are incurred during the application development stage of developing or
obtaining internal-use software, an entity may have to use judgment to
determine how to account for hosting fees paid to a third-party service
provider. ASC 350-40-30-1(a) requires the capitalization of “[e]xternal
direct costs of materials and services consumed in developing or
obtaining internal-use computer software” (emphasis added).
Because hosting an entity’s software is a form of service provided by a
third party, there may be instances in which hosting fees constitute a
service consumed in connection with application development. Such
instances would be limited to when the hosting fees are (1) directly
attributable to the cloud environment used to develop the internal-use
software in the hosted environment and (2) solely related to the
consumption required to develop the internal-use software. For example,
if a company procured a dedicated development environment with a
third-party hosting service provider that was solely used to develop
internal-use software, the incremental fees for hosting services
consumed during the application development stage would be considered
direct costs of the internal-use software being developed and would
therefore be capitalized (as services consumed in the development of
internal-use software). Entities will have to use significant judgment
to determine whether hosting fees are directly and solely attributable
to the internal-use software being developed.
The table below summarizes the different
activities performed and the related accounting for costs incurred for cloud
migrations based on the nature of the activities and the scope conclusion.
Type of Activity
|
Development or Purchase of Internal-Use Software Hosted
by the Entity or a Third Party
|
Implementation of a Cloud Computing Arrangement That Is a
Service Contract
|
---|---|---|
Planning activities
|
Costs expensed as incurred
|
Costs expensed as incurred
|
Hosting
|
Costs generally expensed as incurred (see above)
|
Costs deferred only if prepayments are made; otherwise,
expensed as incurred
|
Configuration of hosted software that is a service
contract
|
N/A
|
Costs deferred, presented with prepaid expenses, and
recognized over the applicable service period
|
Internal-use software development (e.g., rebuilding or
replacing code)
|
Costs capitalized on the basis of their nature
|
N/A
|
Modification of internal-use software code to adapt to
the cloud (e.g., replatforming or refactoring)
|
Costs capitalized on the basis of their nature if new
functionality is added; otherwise, expensed as
incurred
|
N/A
|
Customization of hosted software that is a service
contract
|
N/A
|
Costs deferred, presented with prepaid expenses, and
recognized over the applicable service period
|
Data conversion or validation
|
Costs expensed as incurred unless the entity is obtaining
internal-use conversion software
|
Costs expensed as incurred unless the entity is obtaining
internal-use conversion software
|
Training, indirect overhead, business process
reengineering, general and administrative activities
|
Costs expensed as incurred
|
Costs expensed as incurred
|
Upgrades to internal-use software after completion
|
Costs capitalized on the basis of their nature if new
functionality is added; otherwise, expensed as
incurred
|
N/A
|
Operation and maintenance after completion
|
Costs expensed as incurred
|
Costs expensed as incurred
|
Impact on Existing Capitalized Software Costs
Entities that migrate applications to the cloud should also carefully evaluate
the impact on existing capitalized software costs. ASC 350-40 provides that
significant changes in the extent or manner in which software is used or
significant changes made to the software could require an entity to evaluate the
capitalized costs for impairment in accordance with ASC 360. In addition, some
significant changes may make it necessary for an entity to reassess the
amortization period.
Some cloud migrations might not affect how the associated software is being used.
For example, an entity may rehost its internal-use software with a third-party
hosting service provider and make minimal changes to the underlying software or
the manner in which the entity uses that software. In this instance, the entity
may conclude that it does not need to evaluate the software for recoverability
because there is no substantive change in the extent or manner in which the
software is used.
However, in many cloud migrations, entities may make significant changes to
existing internal-use software or implement new cloud-based technologies that
replace or augment existing internal-use software. These instances will require
entities to use judgment to determine whether capitalized costs should be
assessed for recoverability.
Example 4
Company M’s human resources (HR) department uses an
out-of-the-box on-premise HR software product (Software
X) that M licenses from Vendor P for a five-year term
and implements on January 1, 20X1. Software X contains
different modules for features such as storing employee
data, administering benefits, and tracking employee
compliance. Software X was originally determined to have
a five-year useful life (equal to the license term).
Having grown its workforce substantially, M determines
that it requires more advanced HR software. On July 1,
20X3, M engages Vendor S to obtain all of its HR
solutions as part of a SaaS arrangement. The SaaS
arrangement will commence on a staggered basis for
different modules, with the first module expected to go
live on January 1, 20X4, and all modules going live by
December 31, 20X4. Once the SaaS for all modules is
live, M will discontinue using Software X.
On July 1, 20X3, M determines that there has been a
significant change in the extent or manner in which it
will use Software X. Company M evaluates Software X for
recoverability as of July 1, 20X3, and updates Software
X’s expected useful life (at the individual module
level).
Example 5
Assume the same facts as in Example 4 except that rather
than engaging Vendor S for its SaaS on July 1, 20X3,
Company M switches to Vendor P’s cloud version of
Software X that P offers as SaaS (i.e., a hosting
arrangement that is a service contract). The
functionality of P’s cloud version of Software X is
substantially the same as that of the on-premise
version. Vendor P offers M a credit for the unused
portion of the Software X term license originally
provided (i.e., 50 percent of the original license fee
is provided to M as a credit toward the future SaaS),
and M will pay an incremental fee for the SaaS
offering.
Company M concludes that Software X is not impaired
because (1) M is continuing to use Software X in a
manner similar to how it used that software before
converting to P’s SaaS offering and (2) P is providing M
a credit for the unused portion of the Software X term
license. However, because Software X is no longer
considered internal-use software, M may reasonably
reclassify the costs capitalized (net of accumulated
amortization) for Software X to the same line item on
the balance sheet as that of prepaid expenses since the
carrying value of Software X is akin to a prepayment
made for P’s SaaS offering. Company M will subsequently
present the related amortized costs in the same line
item as that of the other hosting fees paid to P for the
SaaS offering.
Where to Find Additional Information
If you have questions about accounting for cloud
migrations, please contact any of the following Deloitte professionals:
Chris Chiriatti
Managing Director
Deloitte & Touche LLP
+1 203 761 3039
|
Sandie Kim
Partner
Deloitte & Touche LLP
+1 415 783 4848
|
Michael Shrago
Manager
Deloitte & Touche LLP
+1 585 238 3379
|
Sean Torr
Managing Director
Deloitte & Touche LLP
+1 615 259 1888
|
Footnotes
1
Replatforming is often referred to as “lift, tinker, and shift.”
2
In a partial rebuild (often referred to as “refactoring”), an
organization rebuilds application code to optimize the cloud. Partial
rebuilds are often performed with third-party partners through PaaS.
3
For titles of FASB Accounting Standards Codification (ASC)
references, see Deloitte’s “Titles of Topics and Subtopics in the FASB Accounting Standards
Codification.”
4
FASB Accounting Standards Update (ASU) No. 2018-15,
Customer’s Accounting for Implementation Costs Incurred in a
Cloud Computing Arrangement That Is a Service Contract — a
consensus of the FASB Emerging Issues Task Force. For a discussion
of the ASU’s key provisions, see Deloitte’s September 11, 2018,
Heads
Up.