![](media/image1.wmf)

**White Paper:**

**Financial Systems Data Conversion --**

**Considerations**

###### 

###### 

###### December 20, 2002 

## TABLE OF CONTENTS

## 

Background 3

Data Conversion Issues/Questions 4

Scope of the Project 4

I. Conversion Tasks

> Pre-Conversion 5
>
> Develop Conversion Plan 5
>
> Define Function and Data in Legacy System 6
>
> Identify Interfaces 6
>
> Define Functions and Date in New System 6
>
> Determine Security Rights 6
>
> Risk Assessment and Management 6
>
> Determining Data Conversion Requirements 7
>
> Data Mapping 8
>
> Data Clean-Up 8
>
> Ensuring Integrity of Edits and Validation in the New System 9
>
> Establishing and Testing Set-Up Data and Configuration 9
>
> Cutover Tasks 9
>
> Post Installation tasks 10

II\. System Data Conversion

System Conversion Timing

Conversion Options 12

Beginning-of-the-Year Conversions 12

Mid-Year Conversions 12

Incremental Approach to Data Conversion 13

System Conversion Options 13

> Direct Conversion Options
>
> Opting Not to Conduct a Data Conversion 14
>
> Processing New Transactions and Activity Only 14
>
> Establishing Transaction Balances in the New System for Reporting
>
> Purposes 14
>
> Converting Open Transactions from the Legacy System 14
>
> Closed Prior Year Transactions with New Activity 15

III\. Definitions 16

IV\. Contributors 17

## BACKGROUND

Of the many critical tasks necessary to successfully implement a new
financial system, data conversion is one of the most frequently
underestimated. From the outset, it should be understood that financial
systems data conversion is a complex and difficult task that requires
highly skilled staff to conduct successfully. If data conversion is done
right, the new system has the opportunity for success. However,
converting data incorrectly has lengthy and long-term repercussions.

This \"JFMIP White Paper\" is intended to raise awareness of financial
systems data conversion considerations to be addressed by financial
management executives and project managers, when planning or
implementing a new financial management system. (This is not a how-to
manual.) This White Paper updates selected information currently
contained in the JFMIP *Framework for Federal Financial Management
Systems*, FFMSR-0, issued in January 1995, regarding transitioning to a
new system[^1]. This document is not intended to be a comprehensive
system conversion check list. A more comprehensive plan would have to be
developed to guide development of system conversion. Software vendors
frequently have methodologies defined based on lessons learned.

Data conversion is defined as the modification of existing data to
enable it to operate with similar functional capability in a different
environment.

## Automated versus Manual Conversion.

Automated conversion is the process of transferring selected
transactions from the legacy system to the new one, through use of an
automated tool or custom developed software. It could also be considered
an interface. The development of interface software to support the
conversion may be unavoidable for large systems. Prior to determining
that an automated conversion is required, full cost of the conversion
should be developed. Careful consideration should be given to the
cost-effectiveness of developing custom software to perform what is
essentially a one-time task. The conversion might be scrutinized to
determine if modifying the data is a more cost-effective approach.
Conversions become more-than-one-time tasks if the implementation
methodology includes multiple, comprehensive testing cycles of the new
system or dry-runs of the conversion software/processes. Also, if the
legacy system continues to operate then the conversion software may be
needed for future conversions to the new system. Lastly, some conversion
software can become operational interfaces. The feasibility, risk and
resources required for developing custom software should be carefully
evaluated. The volume of data and difficulty in performing an automated
conversion are examples of factors that are considered in determining
whether to use a manual or automated conversion process.

## Data Conversion Issues/Questions

There are also specific issues that apply uniquely to the replacement of
a financial system. This includes:

-   identifying specific open transactions and balances to be
    established;

-   consideration of data conversion approaches and implications;

```{=html}
<!-- -->
```
-   analysis and reconciliation to validate transactions and data; and

```{=html}
<!-- -->
```
-   establishing transactions and balances in the new system through an
    automated or manual process.

This paper addresses the following questions:

-   What are the key considerations regarding data conversion and
    cutover to the new system?

-   What are the best approaches for completing the data conversion and
    cutover?

-   What are the benefits and processes to reduce risks of the various
    approaches?

***Scope of the Project***

Prior to proceeding on to the conversion process, the scope of the
project needs to be determined. The scope of the project will determine
the cost, length of time for the conversion, and the number of personnel
or contractors involved. Answering the following questions may be useful
for determining the scope.

-   What are the outputs of the current system?

-   Are there new data requirements that the new system must meet?

-   What are the priorities and risks with the data conversion?

-   How will continuity be maintained during the conversion/cutover
    period?

-   Are adequate funds available for the project?

-   Are qualified staff dedicated to the project?

-   How much time will be required to complete the data conversion
    strategy that has been chosen?

Examples of issues and questions for consideration when developing the
scope of a data conversion project:

-   How far back will data in the general ledger and other systems be
    converted?

-   Will data in funds that have been closed (expired for over five
    years) be converted into the new system or archived?

-   Does the accounting classification coding structure in the legacy
    system comply with Federal standards and requirements?

-   Will necessary, trained staffing resources be available to complete
    the conversion tasks on a timely basis?

-   Will agency personnel or contractors review and clean-up current
    data in the old system prior to conversion?

-   Is there sufficient time to conduct adequate testing of the
    conversion process to detect and correct errors prior to the
    conversion?

**CONVERSION TASKS.**

There are three primary phases in a data and system conversion. Each of
the phases has multiple tasks attached to it. Pre-Conversion is the most
extensive involving multiple tasks. Cutover may be the second phase but
it is really the last milestone on a critical path. Post-Installation
may seem like a time to celebrate; however, there are tasks critical to
a successful data and system conversion.

1.  *Pre-Conversion.* Activities prior to and leading up to the
    conversion, such as determining the scope and approach or method,
    developing the conversion plan, data clean-up and validation,
    ensuring data integrity, and conducting necessary analysis and
    testing.

2.  *Cutover.* Activities to actually convert the legacy data to the new
    system, such as testing system process and data edits, testing
    system interfaces, both incoming and outgoing, managing the critical
    path, supervising workload completion, and reconciliation.

3.  *Post-Installation.* Activities such as verifying data integrity,
    final disposition of the legacy system data and monitoring of the
    first reporting cycle.

## Pre-Conversion.

Pre-conversion requires many actions. However, if properly executed,
these tasks significantly reduce the risks associated with the cutover
process. Some of the actions are consecutive; however, many can be
performed concurrently.

1.  Develop conversion plan, including the milestones;

2.  Define functions and data used in the legacy system;

3.  Identify interfaces, both input and output;

4.  Define functions and data needed in the new system;

5.  Determine security rights;

6.  Risk

    a.  Perform risk assessment;

    b.  Develop risk management plan

7.  Determine data conversion requirements;

8.  Map data from legacy to new system;

9.  Perform data clean-up;

10. Ensure integrity of edits and validations in the new system;

11. Establish and test set-up data and configurations

An example of concurrent actions are numbers one, two, and three above.
Each of those actions can be performed independently of the others.
Action #11, testing, is an essential element of several of the above
actions and time should be allowed for it.

*Conversion Plan.* A comprehensive, detailed conversion plan, including
time frames for various tasks in the phase, is essential. The plan also
needs to include adequate time for testing, especially when intensive
data mapping and data clean-up are expected. The task of financial
systems data conversion can be a significant part of the financial
system implementation in terms of workload, complexity, risk and cost.
As such, the conversion strategy, methodology, resources, timelines, and
dependencies should be considered early as part of overall strategic and
project planning for the system implementation. The conversion plan
should fully and clearly identify and document the scope of the
conversion, specific transactions and data to be converted (budget,
single year, multi-year, and no-year appropriations), legacy data to be
archived, system inputs and outputs, methodology to be followed, time
and resource constraints. The plan should also identify all dependencies
impacting or impacted by the conversion. Finally, the conversion plan
should include a clear communication strategy, particularly for
concurrent and shared tasks, and performance metrics to ensure tasks are
accomplished in accordance with plan.

*Legacy System Function and Data.* The functions and data of the
current, legacy system need to be defined or described:

-   what data is used in the system;

-   how is it used within the system;

-   what does the system produce (reports, etc.);

-   who uses the information produced by the system;

-   are the outputs of the system used or essential?

*Interface Identification.* Another part of defining the current system
is identifying all interfaces both input and output interfaces.

-   What systems does the legacy system receive data from and what data
    is it?

-   Does the legacy system feed data to another system, if so, what does
    it provide?

*New System Functions and Data.* Financial information is used in
conjunction with programmatic data for analysis and decision-making.
Management's need for financial information should be considered along
with accounting requirements when considering data conversion scope and
timing.

*Security Rights.* Management is not only responsible for identifying
features that are required or desirable in the target system. Management
also determines security rights and access as part of this process.
Security rights includes documentation of:

-   who will have access to add or change data within the system;

-   who can develop reports and management information from data in the
    system without adding or changing data within the system; and

-   who will have read-only access.

The project office will need to be working with users to determine
system control definitions. System control definitions define the
procedures that govern daily work flow and business processes. They also
determine how new features will dictate how the systems are executed and
how business processes function.

*Risk.* The data conversion scope must be determined within the context
of risk assessment. Risk assessment is the systematic approach to
identifying and analyzing risk. It is asking the question: What can go
wrong? Risk management is controlling areas or events with a potential
for causing unwanted change. Potential risks are rated as:

-   Low -- requires some attention as a good business practice. The risk
    can cause delays or additional work that could be contained with
    existing contingency plans or resources.

-   Moderate -- requires attention in the near future. The risk can
    cause slight delay or additional work for a given deliverable or
    task but will not impact the overall project/program budget or end
    date.

-   High -- requires immediate attention. The risk can cause significant
    disruption to the project/program.

With a risk plan, risks to the conversion are assessed and
systematically managed to reduce them to an acceptable level. Risk is a
measure of the inability to achieve overall conversion objectives within
defined cost, schedule, and technical constraints and has two
components:

-   The probability of failing to achieve a particular outcome and

-   The consequences of failing to achieve that outcome.

Constraints on time or funding, can increase or decrease the risk of an
incomplete or poorly functioning new system. Risk factors for
consideration:

-   Will any attributes and criteria be compromised with the approach
    being taken?

-   Will the approach taken degrade performance?

-   Will the preferred approach allow the system conversion to be
    completed within the allowable time frame?

-   Will failure to accurately convert cause any risks?

-   Will the approach impact the critical delivery of products and
    services produced from this system or another system?

-   Will failure of the system to convert on schedule jeopardize another
    system or adversely impact a project's critical path?

-   Does the recommended or selected approach increase or decrease the
    expected amount of testing?

-   Are the automated tools that are being utilized favor one approach
    over another?

-   If there is a contractor involved, does the contractor have the
    ability to perform the conversion?

When developing the risk management plan, there should be coordination
with the Office of the Inspector General and other offices that would or
may be affected by the conversion. The OIG can assist with compliance
issues that may arise when changing business processes or making the
cutover to the new system. Risk assessment and management provides
measures to effectively identify risk, detect problems early, and take
corrective action to eliminate the risk or alleviate the impacts of the
risk.

*Data Conversion Requirements.* Once the scope of the conversion is
determined, the choices made may result in great variations in the
complexity, timelines, cost, risk and likely success. The requirements
to be met by the new system provide the basis for determining the
specific data to be converted. The legacy system data should be
converted to the new system based on a determin-ation that a valid need
for it exists. Examples of actions taken in the conversion process
include:

-   How data will be translated and cross-walked between the two systems
    where different accounting classification coding structures may
    exist.

-   Differences in functionality, work flow processes, and new
    accounting requirements.

There should be clear documentation of how data in the legacy system
will be translated. A crosswalk between the data elements in the old and
new systems should be defined, mapped, and tested.

Consideration should also be given to other systems, both financial and
programmatic, that interface and use elements of the accounting
classification coding structure; particularly with an implementation
that is phased by accounting function. The conversion plan should
include the approach and schedule for updating all systems that utilize
the accounting classification coding structure.

*Data Mapping.* Data mapping is the identification of legacy data
elements that will be continued and converted and the identification of
the data elements required in the new system. Data mapping is done in
order to ensure that each legacy data element is identified and
earmarked to be continued as a new data element or discontinued.
Converted document and account balances including those coming from
manual systems must be traceable to audited sources from the legacy
system in order to support opening balances and related supporting
transactions under the new automated or manual system. Once the mapping
is complete, there needs to be a method of testing the process to assure
completeness and correctness.

Data relationships in the legacy system and the new system must be
documented and understood. To accomplish this a data dictionary should
be established crosswalking the legacy data elements to the new system
data elements. For example, the element PURCHASE_ORDER_NUMBER may be
defined as "\[t\]he number assigned by the Office of Procurement to
uniquely identify a contractual obligation. The value contained in this
field applies to all contractual documents and not just 'purchase
orders'. The data dictionary also contains a description of each of the
data elements, including the file length of the element and whether it
is alpha, numeric, or both. As part of data dictionary development,
parent/child relationships need to be determined; the parent/child
relationships are particularly important when loading data into the new
system. Besides the elements previously mentioned, a data dictionary
should contain the following:

-   Data Element Definitions, such as those previously mentioned.

-   Table Definitions (if the system is table driven).

-   Database Schema.

-   Entity-Relationship Model of Data.

The data mapping effort will include the identification of systems
tables, fields, field length, attributes, whether or not they are
required, default value if required, and source. The actual translation
may take place manually, through the use of automated tools, or through
the use of software developed specifically for the conversion. In any
case, the data elements existing in the legacy system must be translated
and matched to the new system including text fields. Adequate testing
will need to be planned. Overlooking this step may result in significant
delays and increased risk.

*Data Clean-Up.* The objective of data clean-up is to ensure that the
data conforms to business rules and processes and that it is consistent
and complete. The validation and adjustment of open transactions and
data in the legacy system is an essential prerequisite to the conversion
process. The legacy system may contain erroneous and duplicative data,
inactive transactions that should have been closed, open transactions
with error conditions, suspended transactions, and other undesirable
conditions. Errors existing in the legacy system should not be
perpetuated in the new one. Generally it is much easier to perform data
clean-up prior to deployment of the new system than after. Data
validation rules must be identified and implemented. If the format for
date is YYYYMMDD then that rule must be established, checked, and
tested. Any other format for date would not pass edit checks. Since the
data clean up task may be labor intensive, a separate plan, and possibly
a task force, for data clean up may be warranted. There are automated
tools available to assist with this task. Documentation of the process
can provide quality assurance. Significant lead-time may also be
required. Particular attention should be paid to potential problem
areas, such as: inventories, physical assets, contracts, accounts
receivable, or accounts payable. A test database should be developed to
ensure that the data meets all rules and requirements and findings must
be documented.

*Ensuring Integrity of Edits and Validation.* Maintaining data integrity
in the new system is critical. As transactions are entered, they should
be subjected to full data edit and validation.[^2] All transactions,
whether entered manually or through an automated process, should be
subjected to the same edit and validation procedures applied to any
transaction. Bypassing the systems data edit and validation steps during
the conversion process may result in difficult data integrity
deficiencies down the road and increase the risk of future problems.
However, depending on the system, some edits/setups may need to be
"turned off" or not implemented in order to perform data conversion and
loading in a reasonable amount of time. Careful consideration should be
given to any conversion methodology that requires bypassing system
processes that are designed to perform data edit and validation. Only
data that has been thoroughly cleaned and has been tested to ensure that
it meets all business rules and requirements should be allowed to pass
when edits/setups are turned off during transfer.

*Establish and Test Set-Up Data and Configuration.* Configuration and
set up data and user-defined[^3] parameters reflect the agency's
business rules and govern how transactions will be processed where
variations are allowed to be uniquely determined. A successful
conversion is dependent upon complete configuration of set up data,
business rules and other user defined parameters in the new system. A
key objective should be to ensure that set-up data is correctly
established and tested prior to conversion. Incomplete set up data will
likely result in rejected transactions and confusion during the
conversion process. Adequate testing should also be factored into the
conversion plan to ensure that required data edit and validation tables
and values are complete and accurate and that transactions to be
compared against them conform to edit and validation rules and codes.

## Cutover Tasks.

This is the period for implementation of the new system. All of the
pre-conversion efforts have been completed.

-   analyses and mapping of the data are complete and have been tested;

-   the data has been cleaned-up and meets all the edits of the new
    system; and

-   everything has been tested.

At this point a cutover plan has to be developed and tasks scripted,
tested and rehearsed. The cutover plan will define the criteria for
success of the cutover. Also, there needs to be a back-up plan in case
the new system fails to operate as expected or there is a failure during
entry of the data. By this time, there should be a test database that
has been used to test the data mapping process and test data to ensure
that it meets all rules and requirements. Findings from these tests need
to be documented and resolved as a quality assurance procedure.

At this point the actual cutover tasks need to be scripted, tested and
rehearsed. Scripting is:

-   delineating each step in the cutover process;

-   what is to be performed at that step; and

-   performance expectations.

Also there should be a review of the data dictionary to ensure that the
parent/child relationships are adhered to in developing the cutover
process. Again, the script should be checked to ensure that all the
automated inputs and interfaces are included. Script should include
expected results of tests. Finally there should be a mock conversion of
the entire process with all players involved. The mock conversion should
include the possibility of a failure in the data transfer and the need
to fall back to the alternative plan, which may be a return to the
legacy system while the conversion process is reviewed to determine the
cause of failure.

Once the script has been developed, data relationships checked, and a
mock conversion run, the actual cutover is ready to begin. Following is
a list of the steps in the cutover process.

-   Processing in the legacy system is stopped

-   Automated inputs and interfaces are re-routed to the new system.

-   Legacy data is run through a conversion interface and imported into
    the new system following a pre-determined sequence of entry.

-   Based on degree of success of initial operation, a go/no-go decision
    will be made.

-   Assuming success of the conversion, there should be a reconciliation
    of data in the new system with data from the legacy system.

-   Reports should be printed from the new system and compared and
    reconciled with legacy reports.

-   Document adjustments made to converted data as a result of
    reconciliation to provide a clear audit trail.

***Post Installation Tasks***

These tasks may seem minimal, but they are as important as any of the
conversion tasks. At this point the user is faced with a new system that
may have new data input and edit requirements. There may also be changes
in the business rules and processing methods. Users may need some
"hand-holding" until they become familiar with all of the changes in
data input, edit routines, and required adjustments. The program office
will also be involved in:

-   Archiving master and transaction files;

-   Archiving or warehousing closed account data;

-   Confirming that converted data is functioning as designed;

-   Performing post conversion data clean-up;

-   Assessing abnormalities that may appear;

-   Reviewing how manual entries were handled;

-   Verifying that edits function as designed.

***System Conversion Timing***

## Conversion Options.

Key considerations for the data conversion timetable are:

-   What will the live cutover[^4] date be?

-   When will new transactions be entered into the new system and which
    ones?

-   How much data clean-up will be required?

-   What is the timetable for converting legacy transactions and
    balances?

The "go live" or cutover date is frequently, but not always, the
beginning of the fiscal year. From that point forward, all new
transactions will presumably be recorded in the new system and
pre-existing transactions and balances from the legacy system(s) are
established as planned. Although accounting standards govern the timing
of when financial transactions constructively occur, there is some
flexibility as to when both new and prior year transactions and balances
must be actually recorded in the new system. An analysis of when data is
effectively needed for accounting compliance facilitates development of
a timetable for an incremental conversion that meets compliance
criteria, while being cost effective. However, OMB reporting deadlines
for closing the year and auditing financial statements quickly close
that window. Keeping the legacy system working also invokes complexities
for budgeting (e.g. revolving/no-year funds), consolidated financial
reporting (e.g. FACTS I), training, change management, and
reconciliations (e.g. Treasury cash), dictating that the legacy system
should be closed out as soon as possible.

### Beginning-of-the-Year Conversion.

A key consideration in determining the cutover date for the new system
is whether it will occur at the beginning or during the fiscal year. The
assumption for a beginning-of-the-year conversion is that at the start
of the fiscal year, new-year transactions will be entered into the new
system. From that point forward, only adjustments to open prior year
transactions would be updated to the legacy system, until converted.
Conducting the conversion at the beginning of a fiscal year facilitates
tracking of like transactions and allows time for the prior year legacy
transactions to be validated and/or closed. On the contrary, conducting
the conversion at the same time as year-end closing must compete for
resources that are also directed to year end closing.

### Mid-Year Conversion. 

A mid-year conversion may be more difficult to manage in that it
requires careful consideration of the timing of when open transactions
and balances will be converted to the new system, given that new
activity may be taking place concurrently. This places a greater burden
on managing cut-off dates, timelines, internal controls and
reconciliations. Risk is also greater in a mid-year conversion. A
mid-year conversion will also involve more transactions (e.g.
transactions for the year-to-date) that are not a consideration in a
conversion performed at the beginning of the year where the prior years
have been closed and the legacy system retired. On the contrary, it can
also be scheduled at a time of less activity, allowing staff to devote
more time and energy to the conversion.

## Incremental Approach to Data Conversion.

An incremental approach may result in greater control over data and more
cost-effective use of resources. Financial transactions are uniquely
identifiable, allowing for extensive classification of like transactions
and data[^5]. This allows for sorting and segmenting transactions as
needed and enables priorities to be assigned for converting specific
transactions and data, based on when those specific transactions are
required.

***System Conversion Options***

*Direct or Flash Conversion*. In this, there is start-up of the new
system and an immediate discontinuance of the old system. Open data is
converted and transferred from the old system to the new. This would
require that all the data in the legacy system has been cleaned-up and
validated prior to transfer to the new. Testing of the data being
transferred for validity and of the edit processes is critical. If the
pre-conversion actions are done well, there is a low risk of data
conversion failure.

*Parallel Operation*. Under this option, both the old and new systems
run simultaneously for a period of time. This method is expensive and
only desirable in limited, special cases; when there is a need to retain
detailed legacy data to support specific legal requirements or critical
transactions that can only be captured in the legacy system. Also this
may be an appropriate option when business processes have changed and
produce different data or when quality of data in the legacy system is
suspect.

*Pilot Conversion*. One or more locations are converted to the new
system prior to extending the system to the entire agency. The pilot
program might be used when conversion of the data is complex. When data
clean-up is difficult, this method is used to verify that the data
conversion approach used functioned as planned. This involves less risk
than a total direct conversion of the entire agency. This may be
preferred when the new system involves new processes and changes in
method of data input and validation. This process may be used to develop
a knowledgebase that can be used throughout the organization. Pilot
conversion may be useful in documenting configuration using COTS to
achieve a standard system in an agency.

## Data Conversion Options.

# The following should be considered when determining the scope and timelines of the data conversion. A single conversion option need not be selected for all data; different categories of data could be converted using different options, depending upon such factors as volume, amount of detail required and frequency of reference.

-   **Opting Not to Conduct a Data Conversion.** In cases where the
    legacy system data is considered too inaccurate or unsupported, the
    best option may be not to convert specific data. Under this
    scenario, all new transactions at the beginning of a fiscal year
    would be entered into the new system and prior year transactions
    would remain in the legacy system where initially recorded, until
    closed. The key advantages to this option are cost avoidance for a
    difficult data clean-up. This method ensures that only valid
    transactions that can pass all the edits are entered into the new
    system. Under this method, the legacy and the new system operate in
    parallel until the legacy data can be re-entered from source
    documents or transactions in the legacy system can be closed.

-   **Processing New Transactions and Activity Only**. It is assumed
    that all new transactions against the current fiscal year's
    appropriations will be processed in the new system as in a phase-in
    conversion. After the new system goes live, the legacy system will
    contain all transactions relating to prior periods until the time it
    is decided that they will be converted. It should be noted that,
    following the fiscal year end close, numerous open transactions are
    closed over time, and the pool of legacy data to be converted
    becomes gradually smaller. Financial systems staff conducting the
    conversion should analyze the estimated volume of open transactions
    expected and determine the most advantageous time to convert.
    Simultaneously, the planned production schedule of the new system
    should be analyzed to identify deadlines and hence windows, within
    which the data must be converted. For example, new year transactions
    may be delayed while operational staff are conducting year-end
    close. It may or may not be desirable to delay or suspend entering
    new transactions during the conversion period. Considering all of
    these items on balance will help determine the best conversion
    schedule. This may allow some flexibility in balancing workload
    between current operations and conversion tasks. This also involves
    operating two systems in parallel. Those providing data input will
    have to know two systems and business processes and be able to
    recognize which data goes into which system. There is a risk that
    data will be input into the wrong system and increases time spent on
    reconciling accounts.

##### Establishing Transaction Balances in the New System for Reporting Purposes. Account balances may need to be established in the new system to produce timely and accurate reports in the new year and also for funds control. If the new financial system will produce financial statements, then prior year data will be required for producing prior year reports as well as current year balances that require prior year or opening balances in the computation. An analysis of when transaction balances are needed to maintain financial compliance during the transition must be conducted. This may require that an interface or manual process be developed. The key advantage is that greater financial compliance is achieved in the new system and the scope of reporting capabilities is broadened while avoiding the workload of converting large volumes of legacy detailed transactions.

-   **Converting Open Transactions from the Legacy System.** This
    assumes that a full or partial conversion of open detail[^6]
    transactions in the legacy system will take place as in a direct
    conversion. The advantages of a full conversion may be in cost
    avoidance of maintaining the legacy system and in achieving full
    financial compliance in the new system at the earliest possible
    date. This requires that resources are available and a successful
    data clean up has been completed. A variation of this option is to
    consider migrating transactions to the new system only as new
    activity against prior year transactions occurs, similar to a
    phase-in conversion. Under this scenario, transactions would be
    closed in the legacy system on a transaction-by-transaction basis
    and re-established in the new system simultaneously as new activity
    against the specific accounting event occurs. This approach may be
    precluded by large volumes and may cause consolidated reporting and
    reconciliation issues.

-   **Closed Prior Year Transactions with New Activity.** It is assumed
    that it is unnecessary to convert closed detail data in the legacy
    system. The closed, detail data is archived. There are occasions
    however, when subsequent activity associated with a closed
    transaction occurs. For this scenario, consideration should be given
    to whether the new data will be established in the new system as a
    new transaction against a prior year or processed in the legacy
    system. Some "closed" transactions" (e.g. disbursements) cannot
    easily be moved to the new system; therefore, the latter option is
    mandatory. Data mapping becomes important in situations such as
    this; enabling the development of interfaces that can move data from
    the archive into the new system and process it.

**Definitions**

Account Coding Structure -- Sometimes called the line of accounting used
to identify the type of transaction.

Attributes -- Field or column that belongs to an entity. Some attributes
are dependent upon the value of other attributes on the same record.

Conversion -- Modification of existing data to enable it to operate with
similar functional capability in a different environment.

Entity -- Group of related attributes that roughly correspond to a table

**Contributors**

***Joint Financial Management Improvement Program (JFMIP) Steering
Committee***

Joseph L. Kull, Chair, Office of Management and Budget

Karen Cleary Alderman, Executive Director, JFMIP

Jeffrey C. Steinhoff, General Accounting Office

Robert Reid, Department of the Treasury

Kathleen Turco General Services Administration

Kathleen M. McGettigan, Office of Personnel Management

######### Joint Financial Management Improvement Program

# Stephen A. Balsam, Systems Accountant

Bruce Turner, Systems Accountant

Elvon C. Lloyd, Project Manager

######### Office of Personnel Management

# Maurice O. Duckett

######### General Accounting Office

# John C. Martin

######### Office of Management and Budget

# Jean Holcombe

######### Department of the Interior

# Chet Mills

***[Additional Contributors]{.underline}***

Jerry L. Moran, NAID, Inc.

Jack T. Vile, NAID, Inc.

Suzanne Hack, ALLTEL Corporation

Simcha Kuritzky, American Management Systems

[^1]: Since the *Framework* document was last issued in 1995, both
    technology and implementation practices have evolved. Because the
    *Framework* document is comprehensive, this white paper, as well as
    others to come, is designed to update and expand upon selected
    topics that are of critical interest to agencies and oversight
    communities. The goal is to provide current information through
    posting the White Papers series on the JFMIP Knowledebase at
    www.jfmip.gov and to provide a method to vet topics that will be
    incorporated into a later update of the *Framework* document.

[^2]: Data edit and validation refers to the internal system processes
    used to validate data such as matching with values in user defined
    tables and other internal processes.

[^3]: Reference tables that are populated with unique agency specific
    values that are used for edit and validation. Examples are:
    appropriations, organizational structure, programs and activities,
    object classes, identification of business partners, etc., and
    supporting accounting classification/coding structure

[^4]: The official date at which time the new system becomes operational
    and the new system of record.

[^5]: E.g., financial transactions such as undelivered orders, unfilled
    orders, accounts payable and receivable, etc. are uniquely
    identifiable by transaction type, fiscal year, budget year, fund,
    appropriation, program, oprganization, objectclass, etc.

[^6]: For instance, appropriations, apportionments, allotments,
    undelivered orders, unfilled orders, payables, receivables, etc.