SmartLink
ERP

ERP data migration services in Pakistan

ERP data migration is the workstream that decides whether a go live in Pakistan is calm or memorable, and it is the one most often priced as a task. SmartLink Services runs migration from Karachi as its own stream with named business data owners, mock cycles and a reconciliation that balances at row and value level. This page deals with the commercial side rather than the method: what migration costs when it is bought on its own, how long the cycles genuinely take, and how to decide between moving everything in one weekend and moving it in stages. Figures quoted are market ranges rather than our price.

Discuss this service
Cycles
Mock 1 \u00b7 mock 2 \u00b7 final
Reconciliation
Row and value level
Ownership
Business data owners named
Overview

Migration is where ERP projects fail quietly.

Data migration rarely gets the attention it deserves because it looks like a technical task with an obvious answer: move the records across. In practice it is where most of the late surprises live, and the failure is quiet. The system goes live, the balances are slightly wrong, and finance spends the next quarter reconciling.

We treat migration as its own workstream, with named business data owners rather than an IT team guessing at meaning. Source systems are profiled first so that data quality is a measured fact. Mapping is documented per object, cleansing rules are agreed with the people who own the data, and load scripts are built to be repeatable rather than run once by hand.

Every mock cycle ends with a reconciliation at row count and value level. If it does not balance, it is not finished. The cut-off procedure for open transactions is written and rehearsed too, because that is the part that usually gets improvised at the worst moment.

Scope

What ERP data migration covers

Everything below is agreed in writing before any erp & core systems work starts, so both sides know what is in and what is not.

What the work covers

  • Source system profiling and data quality scoring
  • Field-level mapping documents per object
  • Cleansing rules agreed with business data owners
  • Repeatable load scripts, run in mock cycles
  • Row count and value reconciliation after every load
  • Cut-off procedure for open transactions

What you get at handover

  • Mapping specification per data object
  • Cleansing rule log
  • Reload-capable migration scripts
  • Reconciliation report signed by data owners
  • Open-item cut-off procedure

Typically involves

Excel templates
Discuss this service
01

Deciding how much history is worth carrying across

The opening request is almost always to bring everything, and it is almost never the right answer. Full transactional history enlarges the scope, extends the load window on the weekend when time is scarcest, imports years of inconsistent coding into a clean system, and slows daily work in return for records that will be queried a handful of times. It also embeds old problems into a system whose main selling point was supposed to be a fresh start.

A better shape is usually straightforward. Open items and balances go into the ERP, where they are needed for daily operation. History goes into a read only archive that is indexed, searchable and available to the people who need it, with a retention decision attached and a stated cut off date. Prove the archive can still be read after a version upgrade, because an unreadable archive is functionally identical to no archive on the day somebody finally asks for it.

Settle the argument with usage rather than sentiment. How often was history actually consulted in the past year, by whom, and would a report have answered the question. Most organisations discover the answer is narrower than the request implied. One boundary applies throughout. Legal and tax retention obligations are not ours to determine. The client's advisers set the period and the form, and we design the archive and the extract to satisfy what they specify rather than interpreting the requirement ourselves.

  • Open items and balances migrated, with closed history archived rather than loaded
  • A read only archive that is indexed, searchable and proven readable after an upgrade
  • Retention decisions attached to each data set and sourced from the client's own advisers
  • Actual query frequency measured before agreeing how many years of history to carry
  • A written cut off date, published to the business before extraction begins
02

Duplicates, codes and the cross reference nobody keeps

Master data is where the genuine effort sits. Suppliers entered three times with different spellings and two tax numbers. Customers duplicated once per branch because the old system made a shared record awkward. Items that differ only by a trailing space, or by whether somebody typed the size before or after the colour. None of this is visible from a record count, and all of it becomes visible the first time a purchasing report is run on the new system.

Matching rules have to be written down, agreed with the owners and applied consistently, including a survivorship rule that says which record wins and what happens to the transactions pointing at the ones that lose. Alongside that sit the quieter issues: units of measure and their conversion factors, tax classifications, payment terms, and the fields that are mandatory in the new system and simply absent from the old one, which is where a migration turns into a data collection exercise nobody budgeted for.

Numbering is a decision with consequences far outside the project. Renumbering produces a cleaner system and breaks every external reference at once: customer purchase orders quoting your old codes, printed labels, barcodes, supplier catalogues, price lists held by agents. If you renumber, the cross reference table is a permanent asset and belongs inside the ERP where support can reach it, not in a spreadsheet on the migration team's drive. Keeping legacy codes is less elegant and frequently the correct commercial answer.

  • Written matching and survivorship rules agreed with data owners before any deduplication
  • Units of measure, conversion factors and tax classification reviewed as first class objects
  • New mandatory fields identified early, with a plan for collecting values that do not exist yet
  • A renumbering decision taken with external reference holders in mind, not only internal tidiness
  • Legacy to new cross reference held permanently inside the ERP rather than in a project spreadsheet
01

What ERP data migration costs in Pakistan

Migration is normally bought inside an implementation rather than beside it, so the published bands cover both. Market ranges put a focused single site implementation at PKR 800,000 to 1,500,000, five to seven modules at PKR 1,500,000 to 3,000,000, and multi location manufacturing work at PKR 3,000,000 upwards. Migration is a meaningful share of each, and on a legacy estate with several source systems it is the single largest line inside the build. Where it is bought separately, from an organisation that already has an implementation partner, market hourly rates for skilled technical work in Pakistan run PKR 3,500 to 8,000.

Object count is the honest unit of measure. Customers, suppliers, materials, bills of material, price lists, open purchase orders, open sales orders, open items on both ledgers, stock balances, fixed assets with accumulated depreciation, employees. Each object needs a mapping specification, cleansing rules, a load routine, a test and a reconciliation, and each one behaves differently. A migration of six objects from one clean source is a different job from twenty two objects across four systems, one of which is a spreadsheet that a single person maintains.

Cleansing is the variable that ruins estimates, and nobody can size it before profiling the source. We have profiled stock files where item codes had never been counted against the shelf, and customer ledgers where one company appeared under four account numbers with a different credit limit on each. That work is chargeable, and a bad record migrated faithfully is still a bad record with a new system around it. Profile first, then price. Treat everything above as market pricing. Our figure follows discovery, once the object list, the source count and the profiling results are agreed.

  • Priced per data object, each carrying a mapping, cleansing rules, a load and a reconciliation
  • Source system count, since every extra source adds cross referencing and a second definition
  • Years of history carried across, decided before the load routines are written
  • Cleansing effort sized after source profiling rather than estimated from a conversation
  • Number of mock cycles agreed up front, because each one is a full rehearsal
02

How long an ERP data migration takes

Migration runs alongside the implementation rather than after it, so the envelope is set by the programme: six to twelve weeks for a focused single company go live, three to six months for an SME rollout and nine to twelve months for a large enterprise. Within that, the cycle structure is what consumes time. Mock one proves the routines run. Mock two proves they run against cleaned data at something like real volume. The final load proves nothing new and should be boring, which is the point of the first two.

Each mock cycle ends in a reconciliation, and the reconciliation is where the days go. Row counts are easy. Value level agreement is not, particularly on stock where the legacy valuation method and the new one disagree by design. Expect a full working week per cycle on a mid sized scope, more where the data owners are also the people running month end.

What extends a migration is almost always a decision rather than a load. A material classification nobody has been appointed to own. Whether a dormant customer with an open credit note travels or is written off first. Those questions look small in a plan and they stop a cycle dead. We name a business data owner per object at the start, because an unowned object waits for a meeting that keeps being rearranged.

  • Two mock cycles before the final load, each ending in a signed reconciliation
  • A working week per cycle on a mid sized scope, longer where owners run month end too
  • Load routines built to be rerun, with measured runtimes rather than estimated ones
  • A named business data owner per object, with sign off held to that name
  • A delta load procedure for anything created between the final extract and go live
03

Big bang or phased migration

Big bang means one cutover weekend: legacy frozen, everything extracted, everything loaded, one set of opening balances and one system live on Monday. Phased means the new system takes some part of the business first, by site, by company or by module, while the old one carries the rest. Both work. The choice is about which risk your organisation can actually carry, and it should be taken early, because the migration design differs from the first mapping document onwards.

Moving everything at once is cleaner and less forgiving. There is one reconciliation, one opening balance position and no period where two systems both hold live data and disagree about it. The exposure is concentrated: if the load runs eleven hours instead of four, or an interface certificate expired last month, the whole business feels it on the same morning. It suits single entity organisations with one site, a rehearsed cutover and a genuinely tested rollback point. Rehearse on production like volumes, then rerun whatever failed, since a rehearsal with unresolved failures has not finished.

Phased spreads the risk and buys a great deal of trouble in exchange. While both systems are live you need interim interfaces to keep stock and ledgers aligned, a rule for which system owns a customer who trades with two sites, and a consolidation at month end that somebody has to perform by hand. Those interim interfaces are thrown away at the end, and they still have to be built, tested and supported. Groups with several plants or legal entities usually take this route anyway, because the alternative is asking the whole group to change on one weekend.

Ask two questions to settle it. Can the business tolerate a single bad Monday, and can it tolerate three months of running two versions of the truth. Most organisations discover they mind one of those far more than the other, and that answer, rather than a methodology preference, is what should decide the approach.

  • Big bang for single entity organisations with one site and a rehearsed cutover
  • Phased where several plants or legal entities cannot change on one weekend
  • Interim interfaces for a phased approach designed, built and thrown away deliberately
  • A rollback decision time agreed in advance with a named person authorised to call it
  • Manual contingency written for despatch, invoicing and payment during the first days
How we deliver

Delivering ERP data migration

The six steps below run on every ERP engagement, whether the platform is SAP, Oracle, Dynamics or Odoo. What changes is depth, and how many legal entities and sites have to be carried through one cutover weekend.

  1. 01

    Discover

    We follow a real order, a real goods receipt and a real payment run from desk to ledger. What the procedure says and what people do rarely match, and that gap is the requirement.

  2. 02

    Blueprint

    The functional design fixes chart of accounts, entity structure, costing method and document numbering. Nothing here is easy to change once postings exist, so finance signs it before a consultant touches configuration.

  3. 03

    Build

    Configuration is done in a development client and travels one way to test. Key users see each process area demonstrated on their own material and customer records rather than on vendor sample data.

  4. 04

    Test

    Integration testing runs order to cash and procure to pay end to end, on migrated data. Then key users work written scripts, and every defect is logged with the screen, the document number and a severity.

  5. 05

    Go live

    A timed cutover sequence with named owners: final legacy postings, opening balance load, stock count, reconciliation, then the go decision at a stated hour. The rollback point is a restore that has been tested.

  6. 06

    Run

    Hypercare covers the first month-end close, which is where ERP problems actually surface. After that, a named key user group answers routine questions and changes are batched into a release cadence.

Working together

The reconciliation is the product

What survives a migration is not the script. It is the reconciliation pack: the mapping documents, the cleansing decisions with the names of the people who made them, the load evidence and the signed comparison of source against target. That pack answers the only question that matters afterwards, which is how anyone knows the opening position is right. Systems get replaced again in time. The evidence that the numbers were correct on the day of transfer has to outlast them.

Migration also tends to be the workstream that discovers what the rest of the project has assumed. A field that nobody could populate, a code that means three different things in three branches, a balance that has never agreed. Finding those early is uncomfortable and useful. SmartLink Services runs migration with that expectation built in, and will say when the data is not ready rather than let a date carry a load that does not balance.

Credentials

Accreditations behind ERP & core systems

ERP buyers ask two things before shortlisting: which platforms we are accredited to deliver on, and how the system will meet Pakistani tax reporting once it is live.

Oracle

Partner

Oracle E-Business Suite and Fusion Cloud implementation, module extension and release upgrades, with the database underneath sized, tuned and backed up by the same team rather than a separate supplier.

Microsoft

Partner

Dynamics 365 Finance and Supply Chain work, with SQL Server behind the mid-market implementations and Power BI reporting built on the same chart of accounts finance signed at blueprint.

Google

Partner

Google Cloud hosting for Odoo and ERPNext deployments where an on-premises server is not wanted, plus Workspace identity so ERP sign in uses the account staff already have.

FBR digital invoicing

Compliant integrations

Sales tax invoices raised in the ERP post to the FBR system as they are issued. The returned invoice reference number goes back onto the billing document and prints as a QR code.

HIPAA

Compliant practices

Where an ERP holds patient identifiers in billing or receivables, access is limited by role, the tables are encrypted, activity is logged, and we sign a business associate agreement.

Client words

What ERP & core systems clients say

Comments from people who run erp & core systems systems day to day.

  • What sold us was that they argued with our brief. We asked for a reporting layer and they came back saying the reporting was fine, the batch data underneath it was not, and fixing that first would cost less. That turned out to be right. Our first mock recall after go live took an afternoon instead of the better part of a week.
    Finance Director Food manufacturing group, Karachi
  • We had been through one failed implementation already, so we were sceptical of the whole category. The difference here was the migration work. Two full rehearsal loads before the real one, with a reconciliation pack we could check ourselves. Nobody had ever handed us evidence like that and asked us to sign it.
    Head of IT Wholesale distribution business
  • Our cost reports used to show what we had paid, never what we had committed. Once the subcontract orders and approved variations started registering as commitment, the forecast stopped flattering us. It was uncomfortable reading for a month and then it became the most useful number we have.
    Chief Financial Officer Construction and contracting firm
Questions

Questions about ERP data migration

It is usually bought inside the implementation, and market ranges for those run PKR 800,000 to 1,500,000 focused, PKR 1,500,000 to 3,000,000 mid sized and PKR 3,000,000 upwards for multi location work. Bought separately, migration is quoted against hourly market rates of PKR 3,500 to 8,000. The variable nobody can size in advance is cleansing, which is why we profile the source before pricing.

It runs inside the programme envelope: six to twelve weeks for a focused go live, three to six months for an SME rollout, nine to twelve for a large enterprise. Plan two mock cycles before the final load, and allow roughly a working week per cycle on a mid sized scope, most of it spent on reconciliation rather than on loading.

Not during the mock cycles, which run against copies while you trade normally. The final load needs a freeze on the legacy system, usually across a weekend, and that window is planned to the hour with a named owner per task. We also write the manual contingency for despatch, invoicing and payment, so the business has a way to operate if the window overruns.

Yes, and most organisations should. Open items, current balances and the master data behind them have to travel. Closed transaction history usually does not, provided the legacy system stays readable for the retention period your auditor and your tax adviser require. Carrying ten years of closed documents lengthens every cycle and is rarely queried once after go live.

The load is not signed off and the cutover does not proceed on that data. Reconciliation runs at row count and at value level, and a variance has to be explained rather than adjusted away. Manual journals raised purely to force agreement are tracked as defects. That discipline is exactly why we run mock cycles instead of discovering the problem on the weekend.

Extracts are held in named environments with access limited to the people working on that object, and test environments carry anonymised salary and personal data rather than the real values. Copies are logged, and they are destroyed at the end of the engagement. Where a payroll or customer file is involved, the handling terms are written into the engagement rather than assumed.

More in ERP & core systems

More ERP & core systems services

ERP

SAP implementation

S/4HANA and ECC projects run as blueprint, build, test, cutover, with your finance and plant teams in the room.

Open service page → ERP

Oracle ERP & EBS

Oracle E-Business Suite and Fusion Cloud implementation, upgrade and module extension.

Open service page → ERP

ERP consultation & selection

Independent assessment before you commit budget: process fit, licence cost, and honest total cost of ownership.

Open service page → ERP

ERP integration & interfaces

ERP connected to banking, e-invoicing, tax portals, plant systems and third-party applications.

Open service page → ERP

SAP Business One implementation

SAP for growing manufacturers and distributors, with tier-one discipline at mid-market scale.

Open service page → ERP

POS and FBR digital invoicing integration

Point of sale integrated with FBR digital invoicing, so every sale reports in real time with a verifiable invoice.

Open service page →

Worried about the data behind your go-live?

Tell us what you run today and where erp data migration is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All erp & core systems