Conversion Strategy by ohLHqdy0


									                                     The University of Arizona
                                               Mosaic Project
                       Kuali Financial System Implementation
                                         Conversion Strategy

                                                                            Version 1.2

                           Revision History
          Date   Version                   Description                  Author
12/10/08         1.0        Initial Document                      Rachel Serrano
1/21/09          1.1        Revision (various sections from the   Raj Kar
2/15/09          1.2        Updated based on feedback from        Raj Kar
                            Cindy DeMaio

                           The University of Arizona
KFS Implementation – Conversion Strategy                          V 1.1 1/21/2009


1   Executive Summary                                                               3
    1.1 Goal                                                                        3
    1.2 Strategy Approach                                                           4
    1.3 Challenges                                                                  5

2   Scope                                                                           7

3   Conversion Deliverables                                                         8

4   Assumptions/Background                                                          9

5   Stakeholders/Roles                                                              9

6   Environments                                                                     9
    6.1 Conversion Environment Build process                                        10

7   Tactics                                                                         10

8   Success Factors                                                                 15

9   Strategy Roadmap                                                                15
    9.1 High Level Timeline                                                         15

                                      The University of Arizona
KFS Implementation – Conversion Strategy                                        V 1.1 1/21/2009

                                 Conversion Strategy
1     Executive Summary
1.1    Goal
       This Data Conversion Requirements and Strategy document defines the requirements,
       scope, objectives, and strategy for KFS Project for the conversion of Finance, Labor,
       Project Accounting, Purchasing, and Payroll data from legacy systems to Kuali Financial
       Systems (KFS).
      The Data Conversion Requirements and Strategy document is used as follows:
       o The primary use of this document is to record and communicate the data conversion
            scope, objectives, approach, and requirements.
       o The conversion team uses this document to communicate the strategy for successfully
            converting legacy data to the Kuali system.
       o The conversion team uses this document as a road map for performing the
            conversion. All members of the team should understand and follow the same
       o The project manager uses this document to understand how the conversion team plans
            to perform the conversion, and how the conversion effort may impact the overall
      Distribute and communicate the Data Conversion Requirements and Strategy to the:
       o Project manager from the implementation services provider
       o Client project manager, who should sign-off on the conversion requirements and
       o Conversion team members (where applicable)
       o The leads of the production development and support teams.
       o Other process leaders who are responsible for tasks that are prerequisites for
            conversion tasks, or whose tasks are dependent on output from conversion tasks
      Use the following criteria to ensure the quality of this deliverable:
       o Are the project scope and objectives clearly identified?
       o Are specific critical success factors documented?
       o Is the impact of each dependent task from other processes considered?
       o Are the conversion requirements clearly defined, including all legacy applications and
            business objects? Do the definitions indicate the level of detail and history to be
       o Is a disposition path for every existing business object/data element clearly defined?
       o Is the strategy understood by those on the distribution list for this deliverable?
       o Are all assumptions, constraints, and risks that could impact the conversion stated,
            understood, and mitigated?

                                      The University of Arizona
KFS Implementation – Conversion Strategy                                                                             V 1.1 1/21/2009

1.2   Strategy Approach
        Conversion approach will include both automatic and manual processes. Majority of the
        data (reference and transactional) will be converted using automated scripts while a small
        portion of data will be entered manually.
        The following diagram provides a graphical description of the standard conversion
        approach that will be used to convert legacy systems data to the Kuali Financials System.

                             Legacy Systems                                                      Computing
           E                                                                                    Environment
           r                                                          Client w/     Client w/
                                                                      browser       browser
                                 Mainframe                                                                          Database

               Legacy Data                    ASCII
                                             Flat Files                  Intermediate
                                                                                                   Application Tables
                                                                         Staging Area
        a         Relational
        t       non-Relational
          a       Database /
          g     Indexed Files
          e                                                                  Database                     Kuali Systems 3.0

                Spreadsheets /
                  Ext. Feeds

          P                      Extract Data             Load to Staging                       Load
                                                                        Data Validation /
          s                                                             Transformation

        Legacy data will be cleansed either at the source or after the extraction of data in ASCII
        flat files. Data cleansing will include such things as closing open items and deleting
        duplicate data. Data cleansing may also be performed once the data has been converted to
        the flat files. These flat files will then be transferred to staging environment using custom
        SQL*LDR process. Once in the Oracle environment the data will be transformed in the
        staging area and validated prior to loading in the KFS application tables.
        Open Interfaces exist for most subsets of data, and these ensure that data loaded will have
        no data integrity issues and will ultimately support subsequent business processes. Error
        records will be corrected in separate tables for troubleshooting and fixes.

                                                The University of Arizona
KFS Implementation – Conversion Strategy                                                  V 1.1 1/21/2009

                                        Conversion Strategy
                                                                     6. Data Validation
                 1. Conversion Data
                                                                     ,Translation and
                 Mapping/ Legacy
                                                                     load into staging
                 Data cleansing

                 2. Download                                         7. Custom Load
                 Programs                                            Programs

                 3. ASCII Flat File                                  8. KFS Application
                                                                     Production Tables

                 4. Upload Programs                                  9. Reconciliation/
                 to Staging Area                                     Testing

                 5. Description and
                 Creation of                                         10. Write Perform
                 Intermediate Staging                                Conversion
                 Tables                                              Execution Plan

1.3   Challenges
      Amongst many factors affecting successful systems implementations, data conversion is
      critical from both from accuracy and timeline perspective. In fact, a go/no-go decision for a
      cutover in many cases contingent upon successful conversion of required data. Following
      is a brief list of major conversion challenges facing most implementations:

        1. Poor quality data
            Risk: High
            Consequence: Inability to convert legacy data with resultant delay in implementation
            of new Kuali system.
            Mitigation,: Ensure that resources are identified at the earliest opportunity to analyze
            and understand the requirements of the new system. Retain legacy systems until data
            can be cleansed.

        2. Lack of understanding of required key data translation, clean-up and
           transformation criteria
            Risk: Moderate
            Consequence: Possible loss of data during conversion or failure to link data to
            relevant entities in Kuali environment. On-going problems with converted data in the
            new system.
            Contingency: Maintain legacy systems until such times as data in new system can be
            verified. Again, early communication and analysis of the legacy data systems is
            imperative to avoid this

                                         The University of Arizona
KFS Implementation – Conversion Strategy                                          V 1.1 1/21/2009

        3. Systems/environment refreshes
            Risk: Medium
            Consequence: Incorporation of weekly refreshes from Kuali Foundation might
            require additional testing and potential delay in conversion tasks with impacts on
            project milestones
            Contingency: Ensure stand-by backups are available

        4. Timeline
            Risk: High (timescales are aggressive)
            Consequence: Missing of project deadlines and milestones and delay in
            implementation of Kuali 3.0. Delay in dependent tasks could have repercussions in
            terms of go-live/cut-over and incur extra project costs.
            Contingency: Ensure that project plan is watertight and that all phases of the data
            conversion process are included. Project plan and associated milestones should be
            communicated to all data conversion team members.

        5. Availability/Retention of Legacy technical resources to analyze, identify and extract
           legacy data
            Risk: Low
            Consequence: Based on initial extracts, it is assumed that this may not be an issue
            given the extraction programs already tested can be modified for all historical /
            current data extraction.
            Contingency: If Legacy personnel are not made available then this should be brought
            to the attention of the proper level of command in the project. Suitable personnel
            should be earmarked and made available at the earliest opportunity.

        6. Availability of Database Administrator resource
            Risk: Low
            Consequence: Possible non-availability of environment for both test and production
            conversions. Inconsistency of patch-levels across database instances.
            Contingency: Ensure that DBA resource is on site for entire conversion process and
            for support after cutover to Kuali.

        7. KualiFinancials functionality/ Gaps not fully defined and therefore the scope of
           data to be migrated may still be uncertain
            Risk: Low
            Consequence: If the Kuali Functionality is not tightly defined, the scope of the data
            conversion cannot be certain as the type and quantity of data to be migrated would
            not be known.

                                      The University of Arizona
KFS Implementation – Conversion Strategy                                        V 1.1 1/21/2009

            Contingency: All Kuali business processes and functionality as it relates to
            conversion requirements must be fully defined and agreed unequivocally before data
            migration can be executed successfully..

        8. Baseline Application set-up incomplete or not agreed
            Risk: Low
            Consequence: The data migration is dependent on the Application configuration and
            set-up being completed. Any missing set up data will impact on the migration of
            legacy data and consequently on project deadlines.
            Contingency: Application and configuration set-up should be agreed and signed-off
            prior to commencement of any data conversion processes.

2   Scope
      The scope of data conversion for KFS implementation is to ensure that all data for last 3
      (?) years up to the system cutover in FRS is brought over to the new Kuali Financial
      System. Detail scope at the time of writing this document is listed below; further
      information may be available during analysis/design and may be incorporated in future
      versions of this document. It is assumed that no more historical data, other than that
      mentioned, will require conversion. Refer to ‘Conversion Inventory’ and ‘Conversion
      Requirements / Specification’ documents for details on candidate data entities. Data will
      be converted based on the requirements provided by SMEs and Business Area leads.

      Data Entities
      The following is a list of the entities categorized into Reference and Transactional
      data that will be converted as part of the KFS Project implementation.

      Reference Data Entities (Please refer to the conversion inventory for details.)
         o Chart of Accounts (COA)
            - Source is FRS, however, a spreadsheet is created to provide the logic for
            transformation of old object codes to new ones prior to loading in KFS
         o Vendor
            - Source is FRS, but requires an alias table to cross-reference old vendor# to new
         o Labor Distribution Reference
            - Data supplied by SMEs in spreadsheet serve as the source.
         o Purchasing Tables
                o Billing Addresses
         o Vendor Reference Tables
         o Core Tables
                o Country Codes / Zip code
         o Assets
         o Accounts Receivable Tables
         o Cross-Walk
         o Parameters

                                      The University of Arizona
KFS Implementation – Conversion Strategy                                                             V 1.1 1/21/2009

              - to be entered manually through Kuali User Interface (U/I)
            o Workgroups
              - to be entered manually through Kuali User Interface (U/I)
            o Users
            o Netid and other users information extracted from UA LDAP (applicable for initial
              load only)

        Transactional Data Entities (Please refer to conversion inventory for details)
           o Beginning Fund Balance
           o Contract and Grant Account Balances Project-to-date
           o Beginning Balances A/C Encumbrances
           o Labor Ledger Beginning Balance
           o Labor Ledger Encumbrances
           o Account Budget
           o Open Purchase Orders (PO)
           o Payroll Feed
           o Detail Monthly Transactional Data (BI Team)
           o Interfaces (locate the Matrix of external feeds)

3    Conversion Deliverables
     The major tasks and corresponding deliverables provided in this conversion project are:
 Task                                  Description                                         Deliverable

 Define Data Conversion Requirements   Analyze and document the conversion scope,          Data Conversion Requirements and
 and Strategy                          objectives, approach, requirements, and the         Strategy Document
                                       strategy for how the conversion will be
 Prepare Conversion Environment        Prepare the conversion environment for the          Conversion Environment
                                       development and testing of the conversion
 Perform Conversion Data Mapping       Map legacy data files and elements to the KFS       Conversion Data Mapping
                                       table(s) and columns. This map includes an
                                       explanation of business, translation, foreign key
                                       rules, and default settings where applicable
 Define Manual Conversion Procedures   Define procedures for manually converting           Manual Conversion Procedures
                                       applicable business objects through KFS User
 Design Conversion Programs            Design how the conversion programs should be        Conversion Program Designs
                                       coded using conventional programming
                                       techniques including any translation modules
 Prepare Conversion execution Plan     Specify test procedures to be followed for          Conversion Test Plans
                                       performing conversion unit, business object, and
                                       validation tests.
 Develop Conversion Programs           Build conversion programs based on the              Conversion Programs to include
                                       Conversion Program Design                           Conversion Table creation scripts
                                                                                           SQL*Loader scripts
                                                                                           Translation scripts
                                                                                           PL/SQL modules
                                                                                           Réconciliation scripts
 Perform Conversion Unit Tests         Test the performance of each of the individual      Unit test scripts/documentation?
                                       conversion program modules.                         Unit-Tested Conversion Programs
 Perform Conversion Business Object    Test how the converted data performs within the     Business Object-Tested Conversion
 Tests                                 target application.                                 Programs - System Test
 Perform Conversion Validation Tests   Test how the converted data performs within the     Validation-Tested Conversion Programs –
                                       entire suite of target applications.                Integration test

                                        The University of Arizona
KFS Implementation – Conversion Strategy                                                                V 1.1 1/21/2009

 Task                                 Description                                             Deliverable

 Install Conversion Programs          Install the conversion programs that have been          Installed Conversion Programs
                                      coded and tested. Scripts used for conversions
                                      should remain in repository installed until the final
                                      conversion is performed
 Convert and Verify Data              Convert data that has been verified by the users        Converted and Verified Data
                                      before commencement of production operations.

4    Assumptions/Background
     The following assumptions have been made in the development of this strategy:
       o Conversion team will include resource(s) with knowledge of legacy data in FRS.
       o Conversion requirement including clean-up, transformation and business rules will

5    Stakeholders/Roles
     For a detailed list of roles and responsibilities, see the document entitled “Roles and
     Responsibilities.” The following roles are involved in the processes described in this
     o Conversion Lead (F/T) – Provides direction and day-to-day management, coordination
         with business leads. Also helps build ETL mapping, build and loading of data as
     o Technical specialist (F/T) – responsible for extracting data, scrubbing, mapping,
         developing conversion programs, loading and testing data.
     o Business System Analyst (P/T) – provides area specific functional expertise, documents
         conversion requirements, helps in mapping and testing of data.
6    Environments
     The following software and hardware requirements are considered components of this
     conversion effort:

         The application software used as part of this project includes:
                  Database Server - RDBMS 11G
                  Application - Kuali Financial Systems – 3.0
                  Application Server – Tomcat 5.5.16
                  Web Server – Apache xxx

         Hardware Environment (please refer to environment strategy document for
         The hardware and operating software used as part of this project include:
                  Hardware - Dell <Model no>
                  Operating Systems - Redhat Linux <XX>

                                       The University of Arizona
KFS Implementation – Conversion Strategy                                           V 1.1 1/21/2009

        Data conversion will be done in CNV environment and will be maintained by Env
        management team per instructions from conversion team.

6.1   Conversion Environment Build process
Conversion environment (CONV) will be built initially using CFG as a source prior to data
conversion. Subsequently Conv will be re-built on periodic basis from CFG based on milestone
changes with configuration. These configurations might be manually entered by BSAs to rebuild
the environment.

 NOTE: For each environment, migrations always originate from the Dev,
 Config, and Conv environments.
 Configuration, object, and table changes are generated to each environment
 instead of copying them. Conversion scripts are used to migrate converted
 legacy data instead of the data being copied.

7 Tactics
Conversion Inventory (deliverable) will serve as a living document which identifies scope of
entities to be converted and data sources. Please refer to this document for an up-to-date list of
        1. Conversion Data Mapping/Legacy data cleansing
        The data mapping process provides detailed lists of the data sets and data elements that
        will need to be moved into KFS tables during the data conversion. During this process,
        some decisions will need to be made with regard to obtaining information needed by the
        target application that may not be present in the old system. Default settings, user input,
        and new data entries are some of the issues that must be addressed during this phase.

                                      The University of Arizona
KFS Implementation – Conversion Strategy                                           V 1.1 1/21/2009

        The output of this activity is a Data Mapping document that shows what is needed for the
        KFS target module processing to meet business operational requirements and where these
        data elements will come from in the legacy system. This mapping will form the basis for
        the legacy data extract requirements. All scripts and mapping documents will be stored in
        shared network drive (P).
        Once the legacy data to be extracted has been identified then cleansing can begin. This
        will be an ongoing process. The legacy data cleansing should be done, where applicable,
        before the data is extracted from the current systems. If cleansing is done within the
        legacy system, resource(s) from source systems (e.g. FRS) should perform the cleansing
        operation, as they are the owners of the data and therefore have the greatest knowledge of
        the data structures, format and the means of access to the data. On the contrary, when
        data is cleansed after extraction (e.g. chart of accounts) it should be in coordination with
        Business System Analysts.

        2. Download Programs
        Resources from Source systems are responsible for writing these programs (in this case,
        this person is from the project, correct?). These programs are used to extract the
        identified conversion data elements from the current systems in the form of an ASCII flat
        file or Spreadsheet. It is important to remember how the flat file will be structured (the
        order of the records as they are pulled), type of delimitation used, number of records, etc.
        The flat files must match how the interim tables are set up. The output from a download
        program is an ASCII flat file as described in the next section.

        3. ASCII Flat File
        Most database or file systems output data in text form. A comma or space delimited,
        variable or fixed format data file from the existing system should be generated. If you
        cannot find a way to produce clean text data, try generating a report to disk, using a text
        editor to format your data.
        One of the outputs of conversion data mapping is to identify the legacy data element data
        types and precision. After the conversion data mapping is complete, you should know if
        there are inconsistencies between the legacy data types and the requirements for the
        Oracle data types. If there are translations that need to take place, these translations can
        be performed on the legacy system prior to creating the extract or in an interface table.
        Also, if you are creating a fixed length extract file, you need to take into account the
        precision level of decimal numbers.

        4. Upload Program
        Once the data has been extracted to a series of ASCII flat files and physically moved onto
        the same computer as the Oracle RDBMS for staging area, the next step is to load the
        data into a relational database environment.
        Conversion team will write programs to move data, validate data, and insert/update
        standard values into default fields. Usually a single loader program is written for each
        data staging tables using scripts /tools (e.g. SQL*Loader).

                                      The University of Arizona
KFS Implementation – Conversion Strategy                                          V 1.1 1/21/2009

        5. Description and Creation of Intermediary Staging Tables
        Before loading the KFS production tables, the legacy data should first be loaded into
        temporary or interface tables. The interface tables provide a location for you to
        manipulate and translate the data as needed before validating the data and loading the
        application production tables. These temporary interface tables need to be built before
        you run the loader script to populate these tables. The interface tables may be standard
        Oracle Application interface tables or may be custom interface tables. Scripts will be
        written to create these tables and any associated indexes and to allocate storage for them.

        6. Data Validation, Translation and Transformation
        Prior to loading the data KFS production tables there will be a need to validate and tidy
        up certain data items. Scripts will be developed to translate data from the existing system
        format into useful data for the target module where necessary. Some data items may
        need translating into codes in order to satisfy KFS application look-up validation. There
        may be several or no translation programs, depending on both the type of data coming
        across and the format of that data. Conversion team is responsible for transformation,
        translation, and the program to do carry out these while BSAs will provide the business
        rules for translation/transformation. Spreadsheets provided / updated by users will be
        stored in network shared drive (P) under the folder “data conversion”.

        7. Load Programs
        The Load programs will be used to load data from the staging tables into KFS tables. The
        various Programs will also provide error capturing and reporting mechanisms for any
        records rejected during the upload process. Record rejection tends to be caused by either
        failure of validation within the Import routine or because of an earlier failure that has
        gone unnoticed. Conversion team is responsible for writing these load programs as well
        as any error reporting routines. Programs will be stored and maintained in SVN.

        8. Application (Module) Production Tables
        These are the target production tables where the converted data resides. These tables are
        identified early during the data mapping process. These tables drive some of the
        translation programs that must ultimately ensure that 100% of the information that the
        target applications require is present in the final data structures.

        9. Reconciliation/Testing
        Tools or custom reports will be used for even during the pre-conversion steps,
        some type of validation reports are generated from the legacy systems, to be
        compared later with the converted data.
        The approach taken is to use as many standard reports as possible that are
        available in the legacy and target system for the final data validation. If no
        reports support the validation requirements, then custom scripts will need to be
        created for specific validation purposes.
        Data Reconciliation should form part of the testing. This process will compare at
        all stages the number of records extracted with the number of records currently
        undergoing processing and eventually the number of records in the Oracle
        Financials. Reconciliation will include hash totals of certain identified data items.

                                      The University of Arizona
KFS Implementation – Conversion Strategy                                                           V 1.1 1/21/2009

        Testing will include such things as record counts, random sampling as well as
        functional and process testing.
        (rk) – I agree with the fact that listing the items for validation and types of test
        should help in audits. However, types of tests seem to be mixture of activities
        from different areas. For example, Transaction tests may not validate data
        migration and usually if not always outside of data validation.

        We need to clarify who will be responsible for these validations, and expected
        time for validations. Users in some areas have already been doing the validation.
        We need to make sure these are accounted and not a repeat of what’s already
        For “logical errors” on records load, who(roles) will be make sure
        data is corrected?

        Testing will include validation of each of the components that are converted.
        This is not to say that 100% of the detail will be validated, but that a sample of
        each item will be validated for accuracy of the conversion in terms of what was to
        be converted for each row of data (eg are all the fields there and represented
        correctly). Further, row counts will be employed to validate completeness of the
        data to ensure that all that was to be converted actually made it to the target
        database. The following table shows a sample a list of what will be performed.
        Each area will have detailed conversion reviews included for those items that
        impact their area.

        This list is intended to represent most of what is being validated. For a complete
        list of conversion entities, please refer to conversion inventory and the project
        plan. It is possible that there are other items that are being converted that are not                             Formatted: Strikethrough
        covered here, but will be tested nonetheless for completeness, accuracy, and
        ability to be transacted.                                                                                         Comment [RK1]: (let’s be specific and avoid
                                                                                                                          ‘catch all’ statement for entities, I added the
        Conversion      Related items to      Accuracy test           Completeness Test          Transaction Test         reference for this purpose.
        Topic           validate

        Chart of        Chart                 All fields related to   Row count of each          Transactions are able
        Accounts                              each item were          field ties out to either   to be entered for
                                              pulled appropriately    match what was in          these items and post
                        Object Codes          from FRS                FRS or reconciles          successfully.
                                                                      based on known
                                                                                                 Reporting is able to
                                                                      exceptions (eg GL to
                                                                                                 be generated as
                                                                      SL conversion

        Purchase        PO Header             All fields related to   PO heaer and line          PO change and
        Orders                                each item were          counts will be             cancel functionality
                        PO Line
                                              pulled appropriately    validated against          will be tested.
                        PO Line               from FRS                row counts from
                                                                                                 Invoice processes will

                                       The University of Arizona
KFS Implementation – Conversion Strategy                                                          V 1.1 1/21/2009

                        Accounting                                      FRS                     be tested (payment
                                                                        Hash total of PO line
                                                                        dollars matches that    Receiving processes
                                                                        of FRS (this may        will be tested
                                                                        only be for
                                                                        outstanding amount,
                                                                        as opposed to
                                                                        original amount)

        Vendors         Vendor header           All fields related to   Vendor and vendor       Vendor change and
                        information             each item were          address counts will     inactivation testing
                                                pulled appropriately    match up to what
                        Vendor Address                                                          Requisition Creation
                                                from FRS                was expected to be
                                                                        converted (eg no        Purchase Order
                        Vendor Divisions                                Employees or            Creation
                                                                        Students will be
                                                occurred as                                     Disbursement
                                                expected (creating                              Voucher Creation
                                                Parent and
                                                                                                Payment Request

                                                                                                Processor payment

        Accounts        Customer                Customers will be       Row counts match        Invoice writeoff for      Formatted: Highlight
        Receivable                              converted               for customers           converted items
                        Invoice Header
                                                manually, and will
                                                                        Row counts match        Invoice writeoff/credit
                        Invoice Line            therefore be
                                                                        for invoices and        memo processing for
                                                validated at time of
                        Invoice Line                                    invoice lines.          converted items
                                                                        Outstanding AR total    Invoice payment
                                                Invoice information
                                                                        for converted           receipt for converted
                                                will come in the
                                                                        invoices agrees to      items
                                                form of a pre-
                                                defined upload-able                             Invoice partial
                                                format. Each                                    payment receipt for
                                                converted filed will                            converted items           Comment [RK2]: This is not yet defined
                                                need to be tested                                                         Formatted: Highlight
                                                to ensure the
                                                upload was

        Contracts and   Similar to
        Grants          accounts?

        Budgeting       Budget balances         Budget figures          Number of budget        Transaction budget
                                                match for selected      records agrees to       validation, when
                                                combinations            total to be converted   enabled,
                                                                        Total budget dollars
                                                                                                evaluates transaction
                                                                        equals amount from
                                                                                                amount against
                                                                        FRS                                               Comment [RK3]: Not yet decided as to what is
                                                                                                available budget (eg      going to be the source
                                                                                                not previously
                                                                                                account for via
                                                                                                encumbrance, pre-

                                         The University of Arizona
KFS Implementation – Conversion Strategy                                                       V 1.1 1/21/2009

                                                                                             encumbrance, or

           Assets        Asset header          Asset information     Number of assets        Converted assets can
                         information           matches source        converted agrees        be changed or
                                               system                                        inactivated/disposed
                         Asset Depreciation                          Total value of assets
                         information           Depreciation          matches                 Converted assets can
                                               converted correctly                           successfully process
                                                                     Total amount of
                                                                                             through depreciation
                                                                     matches                 Depreciation
                                                                                             calculates correctly

           10. Write and Perform Conversion Execution Plan
           Detail execution plan will be part of the conversion project plan in MS Project and
           stored in network shared drive (p).


8     Success Factors
        The following is brief list of major critical success factors impacting conversion:
           o Early conversion planning and co-ordination across all University of Arizona
             business groups to maximize timely and cost-effective conversion and migration
             development investments
           o Well defined technical architecture strategy, requirements, and application
             configurations that are agreed upon and stable
           o Participation of representatives from each business entity/legacy system group as part
             of the project team helping to ensure consideration and analysis of all business and
             system interface points
           o Timely availability of planned KFS environments
           o Early identification and completion of key data translations, clean up, and
             transformations as a consequence of planned meetings and liaison with the owners of
             the legacy systems.
           o Availability of Kuali functional resources and legacy resources to plan, define
             requirement, mapping, execute and support the migration process.
           o Successful completion of set-up of all required application
           o Availability of fully patched and tested database environment to receive the newly
             converted data.

9     Strategy Roadmap
9.1       High Level Timeline
           o Deliverable #1 - date
           o Deliverable #1 - date

                                        The University of Arizona
KFS Implementation – Conversion Strategy                          V 1.1 1/21/2009

Insert Pipeline Timeline Here

                                      The University of Arizona

To top