Migrating for better A Case study from the Project Management perspective to a data migration

project in a multi brand fashion retail enterprise

By: Ajaz Ahmed (PMP)

Abstract
ERPs are central to any big enterprise. Organizations implement one or more ERP solutions depending upon their
business needs. Some keep upgrading the same ERP to its latest version, while others may switch to an entirely
new ERP. In either case data migration forms an essential part of such an upgrade or implementation. Data
migration is a subset of the overall ERP project, but given the importance, volume of activities involved, and its
impact on the implementation it can well be viewed as a project in itself. Though it may or may not have a separate
project charter, all other project management concepts are still applicable. Data migration being one of the core
parts, the timely completion or delay in implementation of the overall ERP was heavily dependent on this task. The
big bang approach helps achieve the objective in the shortest possible time. But the pitfalls of such an approach
are many, the biggest being business disruption or even a fallback. In such a scenario, the trickle-migration is
better suited. With this phased, sequential migration strategy the objective of smooth transition to the new
system, with minimum business disruptions, can be achieved more or less up-to the expectation.
Introduction:
The below data migration perspective is taken as a case study from an ERP Implementation and Rollout project
undertaken by a leading multi brand fashion retail enterprise in Saudi Arabia, whose business spans over the
Middle East and North Africa, USA and the Commonwealth of Independent States (CIS). This project included 7
different countries, but the case study is based on three countries viz. Jordan, Egypt and Kazakhstan. The
centralized Head Office has implemented an ERP system best suited to the organizations needs. The business
operations spread over different regions across the continents runs on a different ERP system(s).
The business case here was to bring uniformity in data analysis, business projections, planning and decision making
across the regions. This required an integration of business operations across regions to a centralized system which
is based in companys head office. So the objective was to implement only the selected required modules at the
regions while the core functionalities were to be provided by the centralized system. The regional legacy ERP
system(s) was (were) to be phased out. The essential part of this project was migrating their historical (summary)
data and current (master) data to the central system.
Project Scope:
This being a subset an implementation project, the scope of this data migration was limited to an integration of
data from legacy system to the newly adopted system with minimum amount of data loss, maximum possible
accuracy and least possible hurdles to the routing operations like sales, receipts and stock transfers. Acquisition of
hardware, network structure and establishing connectivity was a part of the overall project, hence beyond the
scope of this data migration project.

Migrating for better A Case study from the Project Management perspective to a data migration
project in a multi brand fashion retail enterprise
By: Ajaz Ahmed (PMP)

Project constraints:
1. Rolling over to the new system with no or least possible blackout period for the normal day to day sales
operations
2. Integrating the stocks received during migration period quickly enough without increasing the Lead Time
for delivery at stores to ensure the latest stocks hit the store and are ready for sale
Alternatives evaluation:
The migration comprised of the international brands in which the company trades across the regions. Most of the
brands in all these countries were common to either 2 or more regions. This implied that some or most of the
master data already migrated for a brand X from one country was repeated in another country. This was increasing
data redundancy on one hand and multiplying the efforts of cross-check, and data correction at all the migration
level pre, in process and post migration. An alternative evaluation was carried out and the regions were given
access to the existing master data. They were asked to extract from source only those data which does not exist in
the target data (only the differential was required). For the data common to both countries only additional
attributes were to be migrated like cost and price in their local currency.
Migration Strategy:
The source and target databases were from different vendors, with completely different structures and data
definition. Also noticeable was the fact that although the legacy systems in all the 3 regions were similar, their data
widely in terms of attributes and consistency. Taking these into consideration custom-coding interfaces to prepare
input data was not considered a viable option. So a common migration mapping was developed and ETL - Extract,
Transform and Load strategy was used for data migration. This task was divided among the regional and central
teams, where the regional teams were responsible for the Extract function, while the central team took over the
rest. The output of the extraction was in the form of flat files which were fed to the ERP through standard
interfaces. Extensive training was given to the regional teams as to what was expected on their part and how they
should achieve that. The source (legacy) system was the same in all the regions, so the extraction method adopted
was common to all, and it provided a common input feed to the migration interface. The Transform and Load tasks
were carried out with standard interfaces and batches.
The POS rollout was tightly linked with the data migration the former dependent on the latter. So to ensure that
POS rollout takes place on the agreed date, it was incumbent that the data migration is completed with accuracy a
day before. The accuracy here included the master information, merchandise hierarchy, pricing, seasonality and
other related attributes. The migration was actually driven by the POS rollout schedule. This schedule, at the
beginning of the project was somewhat like a big bang approach. All stores for a particular brand(s) in all countries
to go live on the same date. But with progressive elaboration of the project, it was found that such an approach
was not very feasible due to many a practical constraints. So the approach was revised, the data migration now
drove the rollout. This slowed down the rollout, but it increased the efficiency of rollouts and decreased the
possibilities of a fall back which was more in the earlier approach.

Migrating for better A Case study from the Project Management perspective to a data migration
project in a multi brand fashion retail enterprise
By: Ajaz Ahmed (PMP)

Risks and risk management strategies:

1. High Volume: The volume of data expected to flood the database was too high and posed a risk of
affecting the performance of the servers. The team went ahead with this risk depending on the high
performance servers.
2. Deadlocks:
One of the risks was the clogging of processes due to heavy influx of data. This was realized
as the project progressed. Data flow to different modules was done in the form of scheduled batches. In an
event of such a risk occurrence the response was to disable the batches and enable them on priority basis
so that the system keeps functioning without a shutdown. This was done by 24X7 monitoring of data flow
by the team to ensure that data flows in a sequence and not in parallel thereby making the normal
processing to function smoothly (with a few hiccups though)
3. Delayed shipments:
During this period (from migration to rollout) any new shipment were blacked out
from being processed in the legacy system. Anticipated delays in the extraction and data fixing were bound
to have an effect on the overall migration and the POS rollout, which could have delayed the stocks from
hitting the stores and inability to sell the newly arrived merchandise. To mitigate this risk the migration
team worked out a remigration plan. This comprised of the regional migration teams translating the newly
arrived stock information into a migration file so as to include the same within the migration thereby
greatly reducing the chances of stock sitting in the warehouse awaiting to reach the store and eventually to
the customer.
4. Negative stocks: The first phase of the migration was related migrating master information and replicating
the same to the stores for rollout. Immediately on the rollout, was to kickoff the second phase, i.e. to
migrate the stock on hand position from the legacy to the central system. This had to work in tandem
failing which could have resulted in system showing negative stocks. This risk was mitigated by sequencing
sales integration after the stock was migrated completely and making this a binding criterion. Sales
integration was put on hold until SOH (Stock on Hand) was migrated. This delayed the visibility of sales in
the system, but eliminated the chances of stocks going negative.

Migrating for better A Case study from the Project Management perspective to a data migration
project in a multi brand fashion retail enterprise
By: Ajaz Ahmed (PMP)

Stakeholder Chart:
Regional
Merchandising team

Regional
Merchandising
heads

Regional IT Team

Project Manager

Functional Experts
(HO)

Regional POS rollout

teams

Migration Team (HO)

HO (Head Office)
POS support team
Head of System
Operation (HO)

Data integrators and

Application
Developers
Database Admin and
Batch schedulers

Communication:
Most of the stakeholders mentioned above were identified at the beginning of the project and communications
planned accordingly. Initially things got a bit awry as some of the stakeholders were not included in the RACI
communications matrix. As the project progresses, these were also included in the loop.
The RACI Matrix (R: Responsible. A: Accountable. C: Consulted. I: Informed)
Tasks \ Members

Project
Heads

Regional
Team

Migration
Team

Functional
Team

Application
Developer

Migration planning

R, A

Brand sequencing

R, A

Pre migration system checks

R, A

Pre migration data checks

R, A

Actual migration process

C,I

R, A

Normal transaction
processing/batches monitoring

C, I

Posting and closeout of migration

Data
integrators

R, A

R, A

Post migration process reviews

Applications Handover

Batch
schedulers

Migrating for better A Case study from the Project Management perspective to a data migration
project in a multi brand fashion retail enterprise
By: Ajaz Ahmed (PMP)

Migration Milestones:
Five major milestones were set for this migration project.
1. Migration of Master information this was the go-ahead for the POS rollout at stores
2. Migration of Stock On Hand (SOH) this served as the trigger point for integration of sales coming from the
POS
3. Availability of Stock Ledger this was a point where all transactions including sales, purchases,
adjustments, etc were visible in the stock ledger
4. Posting to finance modules (*) At this point all data from stock ledger and sales from POS along with the
tax information were ready to be posted to financial module
5. Week closing this final weekly phase was a part of migration close out. At this point the business gets to
know its weekly standings for each brand against their budget. Also at this stage many a brand partners get
to know the performance of their brands.
(*) The forth migration milestone had to be removed from the list later as the regional finance teams were not
ready yet with their posting processes.
Impact of overlooking the communication plan:
One of the stakeholders in the migration was the department of finance, which was driving a process of data
integration to the companys financial database and how such a data should be replicated to the financial modules.
One of their primary requirements was how taxes should be reflected and that need was properly taken care of.
During the project it was discovered that the Point of Service at the stores itself had the ability enable or disable
the Value Added Tax during a transaction, which meant that the data flow from the Head Office to the store need
not have this definition flown separately. The team decided to make deliberations on whether to go ahead with
making use of this function. Everybody agreed and the team went ahead with the decision and the regular process
restarted, only to note awhile later that the finance department starting raising concerns that VAT was not being
replicated. That was a big impact and the reason was that particular stakeholder was not taken on board while the
deliberations were taking place, the communications plan was overlooked. Had that happened, this decision could
not have been possible. Now to fulfil their requirements there was a workaround required, and this in a way
introduced scope creep in the project.

Migrating for better A Case study from the Project Management perspective to a data migration
project in a multi brand fashion retail enterprise
By: Ajaz Ahmed (PMP)

Resources:
For the data migration project the company utilized its internal human resources who were experienced with
similar migration projects accomplished within the organization earlier.

Quality assurance:
Data was of utmost importance to this centralization as this was to be transformed into useful information and
business decisions were to be made for the overall business growth. So it was important to allow quality data to be
migrated. Checks were implemented at different levels of migration:

Source 1

Primary Migration File

Secondary File

Source 2

Primary Migration File

Secondary File

Source 3

Primary Migration File

Secondary File

Pre-Migration data
check

In-Process Migration
data check

Clearance or
Rejection

Filtering out
rejected data

Post-Migration data
check
Post Migration
fixing

1. Pre migration data check a set of certain basic checks which cleared or rejected the input data altogether.
The rejected data was sent back to the originating region for review and correction.
2. In-process data check Data which was cleared at the first step went through to a staging phase. A second
check was applied here which filtered out data based on a criteria like mappings, costing, pricing,
classifications, etc. The originator was asked to re-correct these, while the clear data went through to the
final phase.
3. Post migration data check This involved comparison of statistics of data fed for migration and what
actually got migrated. Costs, prices, hierarchy, and other attributes submitted and what actually reflects in
the migration. Any discrepancies found at this stage were escalated to concerned users for the post
migration data fix.

Migrating for better A Case study from the Project Management perspective to a data migration
project in a multi brand fashion retail enterprise
By: Ajaz Ahmed (PMP)

The Migration Schedule Network diagram:

E
F
St

M
J

En

H
I
Tasks

Time (days)

A Pre-migration data check

B Migration to Staging
C Migration to central database
D Master definition to store linking
E Outbound (B2B) Interface deployment
F Replicate to Store Inventory Module
G Replicate master definitions and pricing to stores
H Replicate to warehouse management module
I Regular processing interface deployment
J Stock Migration
K Normal transaction processing and integrations
L Data availability for B2B interface
M Posting to reporting module (closing)
N Posting to Finance module
Paths on the network:
1. A-B-C-D-G-J-K-L
{Critical Path}
2. E-M
3. A-B-C-D-F-K-L
4. A-B-C-D-F-K-M
5. A-B-C-D-H-K-L
6. A-B-C-D-H-K-M
7. A-B-C-D-F-K-N
8. A-B-C-D-I-K-L
9. A-B-C-D-I-K-M
10. A-B-C-D-I-K-N
11. I-K-L
12. I-K-M

(1)
(1)
(1)
(2)
(3)
(1)
(1)
(1)
(2)
(4)
(2)
(2)
(2)
(2)
(14)
(5)
(9)
(9)
(9)
(9)
(9)
(10)
(10)
(10)
(6)
(6)

The task durations are shown here

are from migration of a brand with an
average of 70,000 stock keeping units
(SKUs), having a minimum of 4
attributes associated with each SKU
and the brand consisting of around 10
trading stores

Migrating for better A Case study from the Project Management perspective to a data migration
project in a multi brand fashion retail enterprise
By: Ajaz Ahmed (PMP)

13. I-K-N
(6)
Timeline of the migration project for one country with 21 brands:
Below is the graphical timeline of the major milestones achieved by brand. The taller the bars, the more was the
time consumed (number of days) in achieving those milestones. The lower the bars, the quicker were the
accomplishments of tasks.
The project span over a period of 10 Months (with a few breaks in between) from September 2013 to June 2014
180

Migration: Major Milestones

160

Creation of MOM file for POS

140
T
I 120
M
100
E
L 80
I
N 60
E 40

Stock Migration
RTLog integration to RESA

63
Integration of sales to trandatahistory
36
Integration of sales to EBS STG

8
WOS

14 14

BLA

PAR

11

PUM

24

20 19

19

TAP

20

112

ALA

MON

OKA

GAP

LPS

LSZ

GRG

DYN

ADL

USP

COR

ZYK

QUZ

LVR

STM

CNK

Closing first trading summary (Consider

brand as fully LIVE at this stage)

BRANDS

X-axis represents the abbreviated names of the brands

Y-axis represents the number of days
The number of days is displayed over the Stock Migration bar, as this milestone was a cornerstone of the project
accomplishment of which paved way of the rest of the normal integration processes
EBS posting was later excluded from the scope and was handled separately, hence shown only in the initial 6
brands.
Conclusion:
Data migration forms an essential part of an ERP implementation project, especially where there is a rollover from
an existing system to a newer one. Timely and accurate data migration ensures a seamless switch to the new
system. Migration along with its replication to the point of service destinations guarantees the least possible
downtime in business transactions. Whether or not a data migration has a separate project charter, almost all
project management concepts can still be applied and it may well be treated as a project in itself.

Migrating for better A Case study from the Project Management perspective to a data migration
project in a multi brand fashion retail enterprise
By: Ajaz Ahmed (PMP)

Brand list (in 3 countries):

Brand ID

Brand Name

Brand ID

Brand Name

ADL

Adelisk

LVR

La Vien Rose

ALA

Aldo Shoes and Accessories

MNS

Marks and Spencer

BLA

Suite Blanco

MON

Monsoon

CLK

Clarks

NIN

Ninewest

CNK

Charles & Kieth

NLK

New Look

COR

Cortefiel

OKA

Okaidi

CZN

Collezione

PAR

Parfios

DYN

Dynamite

PUM

Pumpkin Patch

FGK

FG Kids

QUZ

Quiz

FGW

FG Women

SGT

Sergeant Major

FLO

Flormar

SPS

Call it Spring

FNF

F&F Clothing - TESCO

STM

Steve Madden

GAP

GAP

TAP

Tap A L'oeil

GRG
JEN
LEC

Garage
Jennyfer
Le Chateau

TSM
USP
WOS

Topman - Topshop
US Polo
Women's secret

LPS

Lipsy

ZYK

Ziddy Kids

LSZ

Lasenza

About the author:

The writer is a gulf based, certified project management professional (PMP) originally from Aurangabad, India. He
holds a post graduate degree in Computer Applications. He is currently occupied with a leading multi brand fashion
retail chain in Riyadh, Saudi Arabia. His area of expertise includes Project Management, ERP solutions
implementation and support, Business-To-Business (B2B) applications, Application-To-Application (A2A)
integrations, Point of Sale implementation and rollouts. He has experience in ERPs like Oracle Retail, EBS, and
Infinity. He can be reached at ajaz.n.ahmed@gmail.com