How much of my legacy data do I convert to Sage Intacct?
Data conversion efforts can make up a significant cost to the implementation of any ERP implementation. Each company will have different priorities, expectations, and real requirements for their legacy data.
First, a few terms to ensure we have a common language around data conversion.
Legacy Application. The current application that is used and will be replaced by Sage Intacct.
Starting Period. The first year and period of data that will be loaded into Sage Intacct. This may or may not be the first date of data in the Legacy Application.
Setup Data. Setup data is covered under each module and is loaded through Excel / CSV files. Setup data is required to align with all the data that will be converted for reference and needs to be setup prior to the conversion of Historical Data. Examples of setup data includes (reference Addendum: Standard Data Setup and Imports):
Chart of Accounts (Required Dimensions)
Dimension(s)
Entities
Locations
Departments
Customers
Vendors
Items
Classes
Etc.
Accounting Periods
Open and Historical Data. Historical data is defined as data not processed using the Intacct on-line application processes. Historical data includes the general ledger data as journal entries or sub ledgers data such as AP Bills and Payments. There are several types of historical data conversion to consider:
Opening GL Balances. Opening balances are setup based on the earliest data that will be converted from the Legacy Application.
GL Monthly (Period) Net Balances. Net monthly balances start the with initial start date and are processed as summary net changes to the accounts and dimensions defined in the Sage Intacct Chart of Accounts. Net monthly balances support the historical month over month account trend analysis reporting.
GL Detail. Detailed journal transactions replicating historical gl activity both from GL and Subledger activity.
Open AP Bills. Subledger detailed data for open (unpaid) Accounts Payable Bills. Open AP bills are loaded to support the go-live effort and AP department operational support. At times a company may decide to pay older bills to remove them from their conversion effort and to minimize the data conversion effort.
Paid AP Bills. Subledger detailed data for already paid Accounts Payable Bills. Converting Paid AP Bills supports detailed vendor reporting for bills paid.
AP Payments. Subledger detailed AP Payments are required to be applied for sub ledger detailed historical AP bill data. Converting the payments to AP Bills is necessary to support detailed AP Bills status as paid. Conversion of AP Payments is not necessary if only open AP Bills are converted.
There are several approaches that can be supported for historical data. Each approach has its own pros and cons including cost, effort, compliance requirements, and business value. We are outlining the methods we have used for customers successfully in the past.
Option A: Convert All Data
Converting all Legacy data to Sage Intacct includes loading either all your detailed general ledger and possibly AP subledger activity. Converting all data is the most expensive and time-consuming approach.
Pros
One data solution. Data will remain in one single solution for reporting with access to provisioned users. All your historical data is available for reporting in detail in your new Sage Intacct system. This allows for the full reporting and analysis using Sage Intacct for all your data going back as far as your business has been operating or as many years as desired. One data source for any business discovery related responses for as many periods in the past as the business has decided to maintain.
Compliance alignment. Meet any compliance related inquires that may arise with a single application as your data source.
Eliminated legacy application costs. Ensures that a legacy application is shut down thereby reducing software and infrastructure costs along with data security and long-term accessibility risk to the Legacy Application.
Cons
Time consuming effort. Time consuming effort to map legacy application data from the prior chart of accounts to the new chart of accounts.
Challenges abound. Possible challenges may arise as a businesses’ chart of accounts may have changed or adapted over the years to new business, new product lines, or through acquisitions or divestures.
Low probability of use. Based on the cost to convert legacy application data the actual value and reporting requirements may never materialize making the effort 100% cost with 0% benefit. This really relates to the cost of the conversion to the new chart of accounts and system layout. Many data needs for historical data are around one-off inquiry or data room requirements during business valuation / discovery efforts. Data supporting these efforts can be supported with the data in the original, reviewed and accepted formats.
Focuses on rearview mirror. Effort is focused on looking to the past for potential historical financial reporting needs rather than moving forward and focusing on new challenges that have arisen causing the business to move to Sage Intacct in the first place.
Data conversion reconciliation and sign off. Requires proof of conversion reconciliation to ensure any financial reporting in Sage Intacct does in fact reconcile to prior reported financials. This can be a challenge with chart of account changes over time the legacy changes in accounting structure will have to be replicated in Sage Intacct or the accounting differences to normalize all data to the current / new chart of accounts will need to be footnoted.
Option B: Convert Minimum Data – Keep Legacy Application
Convert near term Legacy data to Sage Intacct and keep a minimum cost Legacy Application. Depending on the Legacy Application, this may be the most inexpensive approach that affords simple, validated/reconciled, and accessible method to legacy data.
Pros
Supports period over period trend reporting. Base data is converted for trend analysis by period and is supported with no effort or cost related to the conversion of more legacy application data. Legacy data can be reported as it is and has been prior without any modifications or support.
Quick to implement approach. Converting only period net changes and open balances simplifies the implementation effort by reducing work and data variables. This reduces the implementation cost for both the Client hours and Roghnu hours and moves the Client forward to realize the benefits from Sage Intacct sooner rather than later.
Audit supported. Audit or business inquiry reporting can be completed as it would be in the current state for as long as the legacy solution is maintained.
Cons
Two data solutions. Data will remain in two separate solutions for reporting. Data will reside in both the Sage Intacct and Legacy Application.
Security and accessibility risk. Security and application accessibility both have risks with the legacy application. If it is not updated or security patches applied the risk of issues increases over time. Accessibility to the application is based on the server, or hosting services provided which may or may not be a long term supported option.
Continued legacy application costs. The cost of licensing and infrastructure or hosting of the legacy application may be prohibitive with the access limited to one or a few users in the event data is required to be reported.
Limited data fitness for use. Leveraging the legacy application for reporting does not promote the use of data analytics or research for the data. If limited users are provided access the most likely storage of the historical data will be Excel or CSV exports that reside on shared drives.
Option C: Convert Minimum Data – Detail to Data Warehouse
Convert only near-term Legacy data to Sage Intacct, load all historical detail and summary ledger report data to the Roghnu Data Warehouse and then shut down the Legacy Application. This approach solves historical data access by using the Roghnu data warehouse and allows for data analytics using PowerBI or any other reporting tool that can connect to a Microsoft SQL Server database.
Pros
Full data access. All historical data is accessible using SQL and modern reporting applications.
Quick to implement approach. Converting only period net changes and open balances simplifies the implementation effort by reducing work and data variables. This reduces the implementation cost for both the Client hours and Roghnu hours and moves the Client forward to realize the benefits from Sage Intacct sooner rather than later.
Secure data. Application security can be setup for business users to do discovery and analytics on the data.
Past and current data option. Supports the combined reporting of Sage Intacct and your legacy data in one database if the Sage Intacct to the Roghnu Data Warehouse integration is enabled.
Data analytics supported. Supports long term data analytics in one database for a business using the Roghnu Platform as a Service.
Retire legacy application. No requirement to maintain your Legacy Application saving on licensing and infrastructure costs and security and accessibility risks.
Business continuity and disaster recovery supported. Improved business continuity and disaster recovery planning as your data is secured and readily replicable to the client’s infrastructure from the Roghnu data center. Data is backed up and secured by Roghnu services.
Cons
Two data solutions. Data will remain in two separate solutions for reporting. Data will reside in both the Sage Intacct and Roghnu REDS applications.
Roghnu Data Portal costs. Requires the purchase of the Roghnu PaaS and Data Warehouse services. If you want to combine your legacy data with the new Sage Intacct data, you must purchase the Sage Intacct to Roghnu DW service.
Need help determining which solution is right for you? That’s what we’re here for! Send us a message to get started.