Go-Live Cutover Planning and Conversion Strategy for Discrete Manufacturing Organization (Oracle
Applications ERP)
Introduction: Effective Cutover Planning is very essential for successful Go-Live. Lack of effective planning and
execution during this period may lead to severe reconciliation problems and transaction backlogs. Such problems often
results in roll-back to legacy system or huge cost pile-up to clear the transaction backlog or reconcile the inaccurate
conversion during Cutover period.
Such issues can be prevented if good thought is given to plan the Cutover transition phase in a way that is least intrusive
and in sync with physical situation of the organization. I've tried to explain some of the important considerations for
effective Cutover planning in a discrete manufacturing organization and laid out a step-by-step approach towards the
same. Though I've considered Oracle Application as the ERP platform but most of the steps are common to any standard
off-the-shelf ERP system. The analysis here is restricted to Inventory and Discrete Manufacturing functions which are
often the most complex functions to plan during Cutover due to large volume of data involved.
Cutover Planning: Let us refer the following timeline for this case study (indicative dates used for illustration). Go-Live
transition has been divided into 4 phases as follows:
Production Down-time
starts – 29th Dec,
Friday)
A
Cutover preparation
th
starts – 15 Dec
www.Oraclemfgblog.wordpress.com
B
End of Post Go-Live Syncth
up – 7 Jan, Monday
C
Go-Live
(1st Jan, Monday)
D
Phase A: "Cutover Preparation"
This phase starts post UAT sign-off and goes until actual start date of Cutpver. There are several activities which need to
be planned and executed before the actual Cutover period starts. Following is a list of steps that need to be executed
within this phase.
1. Physical Counting and Stock Adjustments: To ensure accurate inventory migration to a new system at Go-Live
it is essential to have accurate inventory figures in the legacy system first. Since Cutover period is usually very
short to minimize the production down time, physical counting and stock adjustments in legacy system should be
done in Cutover preparation phase. This should be done for all the stores including WIP stores/sub-inventories (if
any) Though exact timing for this activity will vary from one organization to another but it should ideally be done as
close to actual Cutover as possible to avoid any mismatch in inventory balances during the actual Cutover period.
This activity will ensure that legacy system has correct inventory values (and likewise the inventory account
balances) and the values recorded during Cutover can be relied upon for loading open balances to new system at
Go-Live. This will prevent the users from a tedious activity of physical counting during Cutover period as legacy
system has already been brought into sync. with physical stock very recently.
2. Cutover Production Planning: Production should be planned in a way that there is minimum number of open WIP
jobs at the cut-over date. Lesser the no. of open jobs at cutover date, lesser would be the open WIP transactions
and hence reconciliation would be lot easier and less time consuming. There are usually two production scenarios
involved:
i) Short Lead Time Assemblies: If the production lead times are short (as compared to the duration of Cutover
preparation phase), it is recommended to complete the production of as much assemblies as possible before
www.Oraclemfgblog.wordpress.com
Cutover. The objective must be to reach near zero WIP (ideally zero) i.e. to inventorize the assemblies and
convert them as open stock instead of open jobs.
ii) Long Lead Time Assemblies: If the production lead times are long (as compared to the duration of Cutover
preparation phase) it might not always be possible to complete all open WIP jobs by cutover date. Under this
scenario it is recommended that a judicious Job Cutover stage be decided for such jobs and communicated to
shop-floor accordingly. It is very important to stick to this Job cutover schedule as open WIP data will be
compiled based on this information and any deviations should be duly recorded in pre-specified template
(conversion template for open WIP transactions). It usually becomes very difficult to assess the exact status of
open jobs in a short Cutover period and that is the reason it should be a pre-planned activity with all deviations
duly recorded. This process helps in quick compilation of the most complex WIP open data for conversion
during Cutover phase. Further, It should be ensured that all associated sub-assembly jobs be completed and
closed as far as possible before the cutover date.
3. Master data preparation: Master data should be collected and consolidated in pre-decided and well-tested (during
SIT/UATs) data formats in this Cutover preparation phase. All master data elements created until this date should
be collected and verified for correctness after due sanity checks. Master Data elements pertinent to Manufacturing
area are:
 Item Master along-with Item Categories
 Departments, Resources and Resource-Department association
 Bills of Material
 Routing
 User defined costs (if any)
www.Oraclemfgblog.wordpress.com
Since the volume of data involved in a typical Manufacturing organization is huge, getting this master data ready
and validated beforehand goes a long-way in achieving smooth conversion. Any potential data issues are identified
and resolved way earlier then actual Cutover period thus preventing critical situation in short Cutover period.
4. Configuration and Setups: All system configurations and setups (to be initiated post UAT sign-off) should be
completed on Production instance in Cutover preparation stage itself to make the system ready for master data
conversions. If possible responsibility matrix and user assignments should also be completed at this stage itself.
The objective is to complete as much setup as possible leaving only the last minute setups for Cutover period.
5. Master Data Conversions: All master data collected in step Step # 2 should be migrated to Production instance in
this phase to make this instance ready for open transactions data load during the next Cutover phase. Further
there should be a process in place to identify the incremental master data records post this conversion and before
go-live. It can be a SQL script for each of the master data elements where creation date is greater post this
conversion date or there has to be a manual process for this brief duration i.e. whenever a new master data
element is created post this date it must be recorded in a separate template as well which can be loaded again
prior to Cutover phase start date.
6. Smoke Test: It is recommended to carry out a smoke test to identify any potential issues with Production Setups
and overall configuration. Production instance should be cloned post execution of step Step # 5 & 6 to a testing
environment where one complete manufacturing cycle can be executed to validate the core setups and master
data definitions. It will help in early identification of issues (if any) which if not resolved timely may become show
stoppers during Go-Live.
www.Oraclemfgblog.wordpress.com
Phase B: "Cutover Period"
Phase B represents the actual cutover period. No production activity should take place in this Cutover period until
absolutely essential since it may lead to reconciliation problems which might be difficult to overcome during short
span of Cutover. As per our illustration, it starts on 29th December, Friday i.e. no production activity will take place
between Friday morning and Monday morning. Following is a list of activities to be taken care of during this phase:
7. Incremental Master Data Load: Since bulk of Manufacturing master data is loaded in Cutover preparation phase
itself, very few master data records (which have been added since the last load and duly captured as mentioned in
Step # 5), would need to be migrated to Production instance during Cutover. Once incremental master data load is
completed, it should be reconciled with total records in legacy system as per the pre-tested scripts to ensure that
no record has been left out.
8. Incremental Production Setups: There might be few incremental production setups which might need to be done
in addition to Step # 4 to make the Production instance ready for transactions e.g. Opening inventory periods.
9. Open Transaction Data Load: Once all remaining master data has been loaded and Production Setups are
completed, immediate next step is open transactions loading. Following Open Data elements would need to be
loaded for Discrete Manufacturing:
 Open Inventory Stock (including all inventory stores as well as WIP/shop-floor stores) – Since physical
stock was already reconciled in cutover preparation phase (Step # 1), no physical counting or adjustments
are requiring during this short Cutover period. Please note that open inventory stock conversion should be
carried along-with the cost: Average Unit Item Cost (Average Costing) or Standard Unit Item Costs
(Standard Costing)
www.Oraclemfgblog.wordpress.com
 Open WIP conversion – This conversion will be required in long lead time production scenario as
mentioned in Step # 2: Following data elements would need to be converted in case open WIP jobs exist in
Cutover:
o Open Discrete Jobs: Standard / Non-Standard Discrete Jobs which are still under process during
Cutover.
o Open Move Transactions: Operation completion transactions which have already been booked
against these open jobs. There are usually two options for converting move Transactions. (i)
Automated - Convert move transactions through Oracle WIP Move Transactions interface (ii) Manual
– In this approach users need to perform the move transactions against open jobs manually once
Open WIP jobs are converted. It depends upon the availability of time and manpower to choose one
of the above approaches.
o Open WIP Material Transactions: WIP Material (components) issue transactions (time charged) which
have already been booked against these open jobs. There are usually three scenarios for converting
WIP Material transactions. (i) Move Transaction linked: If charge type for material is either "Operation
Pull" or "Assembly Pull", material will be charged automatically as move transactions are converted in
above step or charged during job completion respectively. (ii) Through Interface - Convert WIP
material transactions (for components with charge type as "Push") through Oracle WIP Transactions
Interface (iii) Manual – In this approach users need to perform the WIP material transactions (for
components with charge type as "Manual") against open jobs manually to incur the material cost into
job valuation. It depends upon the availability of time and manpower to choose one of the above
approaches
www.Oraclemfgblog.wordpress.com
Note: WIP Material conversion is very critical activity as it directly impacts the inventory - WIP
valuation. All WIP components which are to be transacted after Job creation must first be converted
as inventory stock in WIP stores (or respective sub-inventories which are mapped as supply subinventories in Oracle BOM) i.e. all material stock which has been consumed until Cutover for open
jobs must be recorded in pre-specified formats and this stock should be converted as open inventory
stock in respective stores as discussed above.
o Open Resource Transactions: Resource issue transactions (time charged) which have already been
booked against these open jobs. There are usually three scenarios for converting resource
transactions. (i) Move Transaction linked: If charge type for resources is used as "WIP Move",
resources will be charged automatically as move transactions are converted in above step. (ii)
Through Interface - Convert resource transactions (for resources with charge type as "Manual")
through Oracle Resource Transactions Interface (iii) Manual – In this approach users need to
perform the resource transactions (for resources with charge type as "Manual") against open jobs
manually once Open WIP jobs are converted to incur the resource cost into job valuation. It depends
upon the availability of time and manpower to choose one of the above approaches
10. Pre-Production Smoke Test: It is recommended to clone the Production instance once again (once all above
steps are completed successfully) to testing environment to carry out pre-production cycle testing once before GoLive.
11. Reconciliation: One last step which is most essential before Go-Live is Open Data Reconciliation. All open
transaction data balances must exactly match with the balances from legacy system in terms of quantity as well as
value. Following are some of the key reconciliation activities:
www.Oraclemfgblog.wordpress.com
 Open inventory stock balances: On-hand Quantity with inventory data compiled from legacy system,
Inventory value with the Trial Balance (Material Valuation Account) in legacy system
 Open WIP balances: No. of Jobs, Material and resource quantities issued to jobs with open data compiled
from legacy system; WIP valuation with WIP account balance in Trial Balance from Legacy system
Note: Since this article focuses on Cutover Planning and Conversion strategy, I've not covered Reconciliation in detail.
I might write a separate post to cover the detailed reconciliation steps involved. There will also be one short article on
Account selection and its financial implications for Open Data Migration in Oracle (For Inventory and Manufacturing
open data).
12. Go-Live: Once pre-production smoke test and Data reconciliation steps are completed successfully, new system
can be pronounced Live and released to business for normal usage.
www.Oraclemfgblog.wordpress.com
Phase C & D: "Post Go-Live Sync-up and Stabilization Phases"
13. Sync-up Activity: Although it is strongly recommended to shut down all operations during Cutover period but still
there might be few transactions which have been carried out in the Cutover period due to their absolutely essential
nature. Such transactions, if any, should have been recorded manually outside the system since legacy system is
frozen as soon as Cutover phase is pronounced active. Users must enter these transactions manually in the
system as soon as the new system goes live. This step is required only in exceptional scenarios and may not be
required if everything goes as planned.
14. Demand Aggregation and Production Plan Runs: MDS is defined post go-live to capture all open demand. MDS
Run fetches all open Sales Orders and Projects against which shipping is yet to be done and consolidates it into
the chosen MDS plan. Master Production Schedule (MPS) and MRP (Material Requirement Planning) plans are
then launched to get the supply plan to meet the open demand as recorded by MDS. All open orders are
automatically netted as supply thus preventing any duplication. Note: "Net WIP Jobs" should be checked in Plan
options. Subsequent plan runs can be scheduled as required by the business.
15. Data References for Business Users: Since business users are usually acquainted to legacy data definitions it
often becomes difficult for them to correctly identify data elements in the initial phase after Go-Live due to probable
changes in data structures or nomenclatures. This affects their operational efficiency and may lead to lags in
transaction recording in new system. Thus, it is recommended to share ready data references to business users for
normal functioning of business processes.
www.Oraclemfgblog.wordpress.com
Hope you will find this analysis interesting; your suggestions and feedback are most welcome!
Regards,
Manu Singhal
Email: msinghal.iitk@gmail.com
The Oracle Manufacturing Blog
www.Oraclemfgblog.wordpress.com