Some of today’s most commonly used enterprise financial management software was first released more than 10 years ago.

Complacency with the current software, the desire to avoid expensive systems integration projects, and time-consuming staff training are all common reasons for not upgrading to new software. But while change is never easy, there are compelling reasons why companies should take another look at migrating to a more current platform and why now is the time to migrate.

Support and Regulatory Changes Coming

Two factors that could negatively impact enterprise financial solutions are reduced or discontinued product support and changes in the regulatory environment. The first is a common challenge with aging software. At some point, vendors will no longer offer updates, patches and integration with other new software offerings. It is better for companies to implement upgrades on their own timetable, rather than when forced to do so.

The second group of factors that will drive financial management software migrations are changes to reporting and auditing requirements. One such change is the possible adoption of International Financial Reporting Standards in the United States. IFRS is supposed to synchronize accounting standards around the globe so that particular types of transactions and events are reported in a similar fashion. The goal is to make international comparisons as easy and accurate as possible. In the United States, the Securities and Exchange Commission  has been researching whether IFRS is actually consistently applied globally and how effective it is for comparing reporting. The SEC will then decide if, and how, IFRS will be applied in the U.S. Options include continued use of U.S. generally accepted accounting principles GAAP, a slow convergence of GAAP and IFRS or a total conversion to IFRS.

Regardless of whether the final decision regarding IFRS is slow convergence or total adoption, consolidation applications are going to require modifications to report under the new standards. If significant work will be required to the existing consolidation application, companies should ask themselves whether that work should be done in the outdated software or whether it would be more cost-effective to combine this effort with a migration to updated software.

Control and audit requirements have also been steadily increasing, since the passage of the Sarbanes-Oxley Act in 2002. While many of today’s popular financial software applications were designed and developed long before these additional requirements, new applications have already added functionality to address these new requirements. These additional options and flexibility in application design can give increased visibility into data that older platforms cannot readily match. An application that is designed with these requirements in mind will reduce the effort required to comply with these new requirements.

Key Migration Considerations for the IT and Finance Departments

The decision to switch financial platforms would typically be led by the finance organization, with input from IT, although either group could initiate the process. Finance and IT each have an interest in the consolidation application, although their focus is typically different: 

  • The finance organization is generally more concerned with the functionality of the application:
  • Does it provide information needed to meet the reporting requirements?
  • Does it allow for the completion of the close activities in the amount of time available?
  • Will it adapt to changes in requirements?
  • Is it easy to use?

The IT organization is typically more concerned with the product itself:

  • Is it reliable and stable?
  • What sort of vendor support is available?
  • Does it meet our standards for network, operating systems and third-party products?
  • What additional products, if any, are required, and do those products meet our standards?
  • How is the product deployed to users?

There is some overlap between the two group's concerns. They both care about reliability and vendor support. In addition, both groups have an interest in security and controls. When one or both groups begin to have reservations regarding how well an application addresses these needs, it is time to begin exploring the options.

Implementing the Migration

Once the decision has been made to migrate to new software, companies must decide how to approach the migration. There are two paths that can be taken, each with its own set of benefits and drawbacks. A company may decide to migrate the application as-is, with little or no modifications to the design, or they may design a new application, taking advantage of features within the new software. With either of these approaches, the migration will also include developing reports and redevelopment of the data load process.

Migrating the incumbent application as it stands is the quickest way to transition to the new platform. With this approach, the old dimensions are migrated to the corresponding new dimensions. The old calculations are then converted to the new calculations, and the old data and journals are loaded into the new platform. Any differences in the attributes and file formats between the two products will have to be addressed during this type of migration.

The drawback to this approach is that it may not create an application that fully takes advantage of the additional capabilities of the new software. The existing application may also not readily fit into the new software, so compromises may be required.

The second approach – designing a new application – can take full advantage of the features available in the new software. This process would start with a review of the current application in order to determine its shortcomings. It should also include a review of how the company has changed since the old application was designed and whether those changes are being adequately addressed. A review of the current reporting requirements should be completed, including any anticipated changes. This would not only include internal reporting requirements but external requirements as well. This is also an opportunity to "clean house” and eliminate any elements of the application or reporting that are no longer required. Using this information, a new application can then be designed.

The new application design would likely include some components of the original application. The entity structure may be similar to the old application since the legal ownership structure is not changing, but the management reporting structure may be very different. The account and any additional dimensions that are available would most likely contain the greatest changes. The attributes for these dimensions, particularly any user-defined fields would also be defined to allow for developing an optimal set of rules and reports. Once the metadata is defined, the outline of the application can be built.

The new calculations can use the old calculations as a starting point. Some of the calculations may no longer be required if the new hierarchies will perform the subtotaling. Many of the calculations are already defined and can be updated to reference the new metadata and be written in the correct format for the new software. Other rules may be redesigned to take advantage of the new platform’s functionality. The goal is to create a set of rules that meet the reporting requirements, result in efficient consolidation times and require the minimal amount of maintenance going forward.

Which approach is best will depend largely on the software being transitioned and will vary greatly from company to company. It will also depend on the objectives of the upgrade. If the objective is only to upgrade to a current product with ongoing vendor support, then straight migration may be best, as it can be done in less time for a lower cost. If the object of the upgrade is to not only move to a current product but to address issues and deficiencies with the current consolidation solution, then a redesign option may be best. While a redesign requires more time and additional costs, the costs are significantly less than a straight migration now and a rebuild at a later date.

How Much Data to Migrate?

Once the application is designed and built, the next most important decision is how much data to migrate. This will impact the time needed for the new consolidation application to go live, and its effectiveness after the migration is complete.

Many companies have preconceived notions of how much history they need to load into the new application, but this should be reevaluated. Considering the reporting that is currently produced. Companies should look at monthly, quarter-end and year-end reports, as well as the 10Q and 10K and the annual report. Typically, the vast majority of the reporting is current year and prior year data. This should be considered the minimum required data to be migrated. An examination of the reporting will find some items outside of the current and prior year, but this is usually a small subset of the overall reporting. In these cases, companies should look into whether the reporting can be accomplished in another manner and whether it is really worth the resources that will be required to load and validate this data. 

Using Outside Resources

With the numerous options, approaches and decisions that come with a migration, it is essential to select the right partner to guide the company through the project to ensure its success. While companies may have plenty of expertise with the incumbent application, they may not have the depth of expertise with the new platform. They may not have the experience of migrating applications between the products and the knowledge to avoid potential pitfalls, or have access to tools that can reduce the manual process of converting metadata and calculations from one platform to the other. To ensure a seamless transition and reduce risk, look for a consultant who is familiar with both your old and new software, as this knowledge is essential for a successful migration regardless of whether the project is a straight migration, a complete rebuild, or a combination.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access