Migrate from BFC to GCR

Center of Excellence · November 2023

1. Abstract

Migrate from BFC to GCR is an important process that does not consist only in migrate cubes or procedure from one Datamodel to another, but several other activities.

The main phases of the migration process are the following:

Be Aware of all the main changes in the Data model between BFC and GCR.
Identify all the possible customizations made in previous BFC implementation.
Agree with the customer on the migration approach that should be followed.
Extract all the main data and eventually adapt to the new required format.
Reconcile Data between BFC and GCR.
Eventually manage the Synch of GCR with any other Data model.

2 . Context

Since GCR has been released in Q2 2023, lots of customers have shown the goal of adopt this solution. If, for the new customers, the adoption is simple since it’s a complete new implementation from the scratch, for existing Financial consolidation customers, the use of GCR implicates the migration from the previous Board Financial Consolidation solution (BFC) into the new one (GCR). In some cases, migrate to GCR will also implicate migrate from Board 10 to Board 12.

The aim of this article is to facilitate this migration by giving some practical guide and best practice.

3. Content

3.1 What has changed in GCR

3.1.1 Separation of capsule – Data Load & Process

Data Load capsule is now separated from the Process capsule. This should be a security consideration. “To Do List” no longer exists. If application level security has been setup, then this should be reviewed.

3.1.2 Entities

For the following entities, have been done changes as detailed below:

Conso Node : Node 99 is no longer required
Movement : Codes Changed
Movement Group (acc) : Codes Changed
Movement Group : Codes Changed
Movement Translation Rate : Codes Changed
Conso Node Type : Codes Changed
Statement : Codes Changed
Super Settings (Now re-named to Application Settings) : Codes Changed
All the Codes “99_Not applicable” are changed to “_ Not Available”

3.1.3 Conso Layer Value Cube

Due to Data model review and optimizations, the CLV is not used anymore along calculation, but technical cubes are used in the calcs, and CLV is used only for reporting purposes.

Changes in Dimensionality of CLV

BFC 4.x / BFC 5.x	GCR
Month	Month
Reporting Unit	Reporting Unit
Consolidation Node	Consolidation Node
IC and Related Parties	IC and Related Parties
Account	Account
Custom 1	Custom Key*
Movement	Movement
Layer	Layer
Custom 2	-
Investment Cost	Investment Register
Scenario	Scenario
-	Adjustment Number

* Custom Key branches into Custom A, Custom B, Custom C, Custom D, Custom E.

3.1.4 Local Account

Local Account is now a concatenation of Reporting Unit & Local Account i.e. this makes it unique for each Reporting Unit. This may require a change in case the local data load process was customized for a customer.

3.1.5 Local Account to Group Account Map

This map is now Month and Scenario specific. Therefore a process of copying map from prior month may be added to the data load process.

3.1.6 Data Load Templates

Due to change of dimensionality of the CLV cube, the data load (both Group and Local) needs to be reviewed and retested.

3.1.7 Adjustment Upload Templates

Due to change of dimensionality, the mass upload template should be reviewed.

3.1.8 Movement Saving Settings

A reverse logic has been built in GCR in comparison with BFC in relation to the Movements Saving Settings.

BFC: Users identify specific movements for which it is required to save data entered

GCR: Users identify specific movements for which it is required to clear data entered.

3.1.9 Investment Cost members

Investment Cost Entity does not longer exist anymore. The Equity Pickup is managed trough a specific ADJ number. Instead, members as re-valuation/de-evaluation are managed trough the new entity “Investment Register”

3.2 Migration Approach

3.2.1 Identify customization in BFC

List of all customizations done in BFC
List of cubes added for this customer
List of entities added for this customer
List of relationships changes
List of any data readers (text and/or SQL)
List customer-specific reports
Review security setup
List out all the integration points with other models (such as Planning)

3.2.2 Migration approach (To be discussed with customer)

Will all the data be re-consolidated in GCR? For example, if the customer’s first month in BFC in Dec.18, will GCR also need to be consolidated from Dec.18 or we migrate data from CLV for Dec.18 till a few months before current?

Option 1: Reconsolidate all data

This case allows for more rigorous testing and confidence to the customer. However, it does require more time to reconcile to existing data in BFC. Other issues could be : hierarchy changes or settings to dimensions over time.

Option 2: Load data and only consolidate current year

List out cubes that need to be extracted from BFC and those that need to be populated in GCR.

3.2.3 Migrate the BFC Data model and capsule (If needed)

In the case where migration is from BFC4 /B10 to GCR/B12, follow through the process of migrating the data model & capsules to B12. No regression testing is required (and also do not run any processing in the migrated database)

This activity helps to easily review data or write procedures (see next step) to extract specific data when required.

3.2.4 Create a “BFC-GCR Migration” capsule

Create a new capsule – this capsule may have multi db screens that can show data from either GCR or BFC. As well, if any procedures are written – specific to the migration, they can be stored in this capsule.

This capsule can be useful to compare and reconcile date between BFC and GCR.

3.2.5 Load from source or from BFC – Where is the data in BFC?

For the months already consolidated in BFC, it is best to load data from BFC into GCR. Pulling data from source systems again adds the risk that source data may not be the same.

Below list gives a quick reference of cubes where BFC data exists (this is not an exhaustive list)

Data	Cube Name
Ownership Input	V179 – Ownerships (input)
Holding Input	V193 – Holdings (input)
FX Rates	V052 – S X-Rate (Closing) V054 – S X-Rate (Average)
TB Group COA	V319 – Load Conso Layer Value
TB Local COA	V218 – Local Trial Balances
Local-Group Mapping	V219 – Local Account Map (+) V220 – Local Account Map (-)
IC Map	V343 – Map Intercompany (txt) (this is a txt cube, whereas GCR is an integer cube)
Historical Values	V128 – Conso Value (L1 at Group Currency for HIS Accounts) (bear in mind that values in this cube in Layer 2 may need to be manually entered due to Adjustment Number in GCR)
Movement Schedule	V001 – Conso Layer Value (important to use specific selections)
Adjustments	V143 – Conso Adjustments (Debit) V142 – Conso Adjustments (Credit)

Example of an extract from BFC:

When running consolidation in GCR for historical months, most of the above data can be loaded via the Smart Import Object provided in the relevant screens. For those that do not have Smart Import Object, we suggest using the BFC-GCR capsule and create a Smart Import to load the data or write a specific DR for this purpose.

When directly populating data in GCR (instead of running conso processes), here are some cubes that can be loaded:

[DE] - Conso Layer Value L01 (No CN)
[CONSO] - Conso Layer Value L01
…
[CONSO] - Conso Layer Value L13
[REP] - Conso Layer Value Reporting
[CALC] - Adjustment Journal Credit
[CALC] - Adjustment Journal Debit
[CALC] - Conso Adjustment Debit
[CALC] - Conso Adjustment Credit
[CALC] - S X-Rate (Closing PY)
[CALC] - S X-Rate (Average PY)

3.2.6 Integration with Data sources

If configuring GCR in a new server, the data source connection (if any) as well as the Data Readers must be re-created. These can be a straight one-to-one copy from the existing BFC model.

It is recommended that at least one or two months are run in parallel between BFC and GCR using the data sources. This will ensure that there is no risk of data mismatch.

3.2.7 Reconciliation between BFC and GCR

To facilitate reconciliation of data between the two model, it is suggested to load the BFC Conso Layer Value cube in one of the available customizable cubes (a straight extract – reload, considering dimension code changes).

Here is an example of such a report (created in the BFC-GCR Migration capsule):

3.2.8 Synch with other Board Data models (Example: Planning)

In cases where there are integration with other Board models – e.g. synch of master data, actuals data, planning data, etc., the following should be considered:

Relationship Tree changes in GCR – how does this impact other models
Changes to codes of entity members (e.g. Statement entity)
Data extract – changes in dimensionality – changes in ASCII Data Readers mapping.

3.3 Security Setup

If customers are moving from B10 to B12, there may be a need to setup security based on Subscription Hub and all it’s enhanced features.

3.4 Some Tips

In some screens, data can be loaded for multiple months. To this, it may be required to change the “Month” pager to deselect “No All”
Make a list of any changes done in the standard capsules
Put a “Go To capsule” at least in Data Load & Process capsule for convenience
Consider putting any Mapping / Relationship screens related to Reports in the Reports Capsule. This will avoid the need for modifying the standard Admin capsule

4. CONCLUSION

Migrate from BFC to GCR is a process that can differ in every implementation. It will require always some effort from Board or partner consultants, however following this article can help you to understand which is the best approach and which are the most important attention points.

Related Content:

How to update GCR version

Center of Excellence · November 2023

Thanks, @Eva Kalia and @alenzi for the insights on this article!