Migrate from BFC to GCR

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: 

  1. Be Aware of all the main changes in the Data model between BFC and GCR. 
  2. Identify all the possible customizations made in previous BFC implementation. 
  3. Agree with the customer on the migration approach that should be followed. 
  4. Extract all the main data and eventually adapt to the new required format. 
  5. Reconcile Data between BFC and GCR. 
  6. 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 




Reporting Unit 

Reporting Unit 

Consolidation Node 

Consolidation Node 

IC and Related Parties 

IC and Related Parties 



Custom 1 

Custom Key* 





Custom 2 

Investment Cost 

Investment Register 



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) 


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) 



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 



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: