Organizational Issues Relating to Migration

Overview

If you are using the Former Budgeting (FB) system in your production environment and you would like to implement the Budget Control System (BCS), you may need to study your current budget application to identify the key incentives for using the Budget Control System before going into details concerning the migration of budget data.

If one of the drivers is the need to change existing FM master data structures , this does not mean simply adding new FM master data objects(that is, account assignment elements) to the budgeting scope (for example, the funded program or grant). You may also need to change the hierarchy and/or the IDs of the currently existing FM master data objects, such as the commitment item, funds center or fund. In such a case, you should consider carrying out a “start-from-scratch” new implementation of BCS, and not migrate your existing budget data from Former Budgeting.

As a general rule, all data should be migrated on a one-to-one basis, meaning that budget addresses used in the source system (FB) should be equal to the ones in the target system (BCS).

The migration process should be based on discussions in your organization concerning the following questions, dealt with in greater detail in the migration checklist :

  • which budget horizon must be covered

  • what data is to be migrated

  • when will migration take place

  • treatment of“historic” data

  • management of the cutover procedure

  • how to handle special processes

The migration of budget data is then done at the level of:

  • Financial management area

  • Fund

  • Fiscal year

  • Budget version

Time Horizons

In FB, budget horizons are maintained via the budget profile. The following budget horizon types are available:

  • periodic

  • annual

  • overall

Using the above categories, the following combinations are then possible for BCS:

  • Annual

  • Annual + period values

  • Overall

  • Overall + annual

  • Overall + annual + period values

Note that in BCS you will only have annual and period values, with the annual values being the sum of the period values. See Time Horizons for Migration .

What Data is Migrated?

Two scenarios are provided for the migration of budget data:

Both processes can be re-run several times. Note the following:

  • For totals-based processing , data that has already been migrated automatically gets deleted in a first step, followed by the creation of the budget records in a second step.

  • Within the context of document-based migration , you can decide to run a full migration, which involves the reprocessing of already migrated FB documents that will delete the corresponding BCS documents before the migration takes place. Alternatively, you can do a delta migration, meaning that only FB documents that have not yet been migrated will be processed.

    Also for document-based migration, existing data in the target BCS will not be affected by the migration run, apart from the deletion of entry documents, if you are carrying out a full migration.

  • You can carry out document-based migration even after entering data directly in BCS. However, for totals-based processing, migration is only possible if you do not have data in BCS, apart from data generated by a previous run of a totals migration. In this case, data that already exists automatically gets deleted in a first step, followed by the creation of the new budget records in a second step.

For further information, see the above links and Basic Migration Rules .

The Best Timing for Migration

Theoretically, you can migrate your FB data at any time within a budget year or at the end of a fiscal year. However, please note that the timing of your migration may have an impact on the possible migration scenario!

  • Treatment of historic data – BCS can replace FB at any given time. Technically, there is no need to migrate any budget data, since BCS will work without any historic data at all.

    However, for reporting and budget preparation purposes, it may be necessary to migrate existing budget data. This could also be relevant for availability control purposes within the context of checking overall funds.

  • Regarding the data of previous years, it is sufficient to migrate at the totals level. Data of the current year (that is, for the year that BCS gets activated) has to be dealt with using document-based migration.

  • For reporting purposes, you can still access all FB data using the existing reporting tools.

Management of Cutover Procedure

As soon as the new functionality is available in BCS, the existing, previous data can be replaced. Two general possibilities exist for the cutover phase, using the so-called “wall-to-wall” and the “parallel run” cutover.

  • For the wall-to-wall cutover , Former Budgeting data remains current until Day X. For Day X + 1, BCS will be in place to take over. This approach is the one most commonly used.

  • It is also possible to have FB and BCS running in parallel for a certain time, with FB active and a switch-over planned for a given date (after activation of BCS).In this scenario, you can already set up the budget (and posting) structure as well as import budget data. However, synchronizing budget data if you are carrying out budget processing (such as transfers, etc.) will in this case be a manual task. You can apply this scenario especially to those cases in which no AVC functionality is required.

    Caution Caution

    If you have both budgeting systems running in parallel, some processes, such as Revenues Increasing the Budget (RIB) or the Budgetary Ledger may lead to processing problems.

    End of the caution.
Special Processes in Budgeting

In Former Budgeting, there are processes where data migration may not be useful, since FB and the BCS follow a different processing and database update logic.

In most cases, you can use alternative processes to “rebuild” the budget records. Some of these special areas are: