Data and System Migration

Data and System Migration: The Compliance Playbook Every Indian Business Needs in 2026

In 2026, any Indian business migrating its ERP or accounting system must treat the project as a regulated compliance event, not a routine IT upgrade. Your migration must preserve eight years of books under Section 128 of the Companies Act 2013, six years of GST records under Section 36 of the CGST Act 2017, honour DPDP Act 2023 data-deletion obligations, and produce a signed audit trail that satisfies both your statutory auditor and any future tax-authority examination. A cutover that skips these controls does not save time — it creates liabilities that compound for years.

Why Data and System Migration Is a Compliance Event, Not an IT Task

Most Indian finance teams still classify a system migration as an IT project with an IT budget and an IT sign-off. That framing is wrong, and the cost of getting it wrong is financial — sometimes severely so.

Consider the full legal landscape governing your data:

• Companies Act 2013, Section 128 requires every company to preserve books of account — ledgers, day books, cash books, cost records and supporting vouchers — for at least eight financial years. Rule 3 of the Companies (Accounts) Rules 2014 permits electronic records, but they must remain accessible and printable on demand at any point within that window.
• CGST Act 2017, Section 36 requires every registered person to retain accounts and records for 72 months (six years) from the due date of filing GSTR-9 (annual return) for the relevant year. For FY 2026-27, the retention clock runs until at least December 2033.
• Income Tax Act 1961, Section 44AA read with Rule 6F requires specified professionals and businesses to maintain accounts for six years from the end of the relevant assessment year.
• DPDP Act 2023 creates the opposite obligation: personal data must be erased once the purpose for which it was collected has been fulfilled. Carrying employee PAN, Aadhaar-linked payroll data, or customer contact details into a new system without reviewing retention periods creates fresh exposure precisely at the migration moment.

The governing rule for most companies is eight years under the Companies Act. Your migration plan must guarantee that every record inside that window is either migrated intact into the new system or archived in an auditable, retrievable format — with the legacy system no longer required to access it.

The Seven-Stage Migration Lifecycle

A migration executed without a formal lifecycle structure almost always produces compliance gaps. Use the following stages as a project checklist.

Stage 1: Discovery

Inventory every source system, database, integration and custom report in scope. This includes the main ERP or accounting package (Tally Prime, SAP, Oracle, Microsoft Dynamics), GST filing software, TDS/TCS tools, the payroll system, the fixed-asset register, any banking APIs, and the shadow Excel databases every operations team has quietly built over the years. You cannot migrate what you have not catalogued.

Stage 2: Scoping

Decide what data moves to the new system, what is archived in a read-only store, and what is purged — with a written, approved justification for each category. Purge decisions must be tested against the retention minimums above. Never delete data solely because it looks "old."

Stage 3: Schema Mapping

Map source fields to target fields with explicit transformation rules. For Indian systems, mandatory validation rules include:

• GSTIN: 15-character alphanumeric; first two digits must match the state code
• HSN/SAC codes: 4, 6 or 8-digit depending on the supplier's applicable turnover slab
• IRN (Invoice Reference Number): 64-character hash assigned by the Invoice Registration Portal (IRP) — must remain linked to the source invoice in the new system
• TAN / PAN: 10-character format with check-digit validation
• Bank IFSC: 11-character format

Stage 4: Data Cleansing

Duplicate vendor and customer masters are the single most common root cause of post-migration mismatches in Form 26AS / AIS (Annual Information Statement) and GSTR-2B reconciliation failures. Run deduplication before the mock load. Validate all GSTINs against the GST portal's GSTIN verification API. Remove vendor records with no transactions in the past three years only after confirming they carry no open advance, retention money, or disputed balance.

Stage 5: Mock Load (Minimum Two Full Rounds)

In each mock, reconcile:

• General ledger opening balances by major head — zero-rupee tolerance
• Accounts receivable and payable ageing bucket totals
• GST electronic credit ledger balance per GSTIN
• TDS payable and advance tax balance
• Fixed-asset gross block and accumulated depreciation per asset class

Any unreconciled financial balance is a showstopper — do not proceed to the next stage.

Stage 6: Cutover

Freeze legacy transactions at a clean regulatory boundary. Midnight on the last day of a GST return period is the ideal cutover point because the closing GST ITC balance aligns with the last GSTR-3B filed. Export final data, migrate, validate, and obtain named written sign-off from the CFO, Head of Tax, and IT Project Manager before go-live.

Stage 7: Hyper-Care

Run parallel systems for at minimum two full month-end closes. Reconcile every sub-ledger independently on the first close. Document every break, its root cause, and the correction applied. This documentation becomes primary evidence for your statutory auditor's IT general-controls testing under SA 315 (Revised 2021).

GST-Specific Migration Risks — and Exactly How to Fix Them

GST is the highest-risk compliance area in any Indian migration. Errors in ITC (Input Tax Credit) history compound directly into GSTR-9 for the migration year and can carry forward into the next year.

Risk 1: ITC opening balance not migrated correctly. Obtain a signed screenshot or export of the Electronic Credit Ledger from the GST portal on the last day before cutover. Compare this to the opening ITC entry posted in the new system. Any shortfall will appear as a GSTR-9 mismatch. Fix: Reconcile to zero before go-live; post a manual opening journal with documentary support if a minor rounding difference exists.

Risk 2: E-invoice IRNs becoming orphaned. If your new system assigns fresh internal document numbers without retaining the original IRN, you will not be able to reconcile your outward supply register against GSTR-1 auto-populated data on the GST portal. Fix: Map the IRN as a non-editable reference field in the new system. Historical e-invoices must carry their original IRN, not a new system-generated ID.

Risk 3: E-way bill cross-references breaking. E-way bill numbers reference the source invoice number. If invoice numbers change during migration, every e-way bill from the legacy period becomes an unmatched record in any scrutiny exercise. Fix: Carry forward the original document number as a legacy_doc_ref field; never renumber historical documents.

Risk 4: ITC reversal history not migrated. Reversals under Rule 37 (non-payment to vendor within 180 days), Rule 42 (exempt or common inputs), and Rule 43 (capital goods) must migrate with their original reversal dates and amounts. Fix: Extract a dedicated reversal register from the legacy system and import it as a separate data set with its own reconciliation sign-off.

DPDP Act 2023: The Retention Obligation Your Migration Cannot Ignore

The Digital Personal Data Protection Act 2023 creates obligations that run in the opposite direction to statutory retention law. Where tax and company law say "keep this for eight years," the DPDP Act says "delete personal data once its purpose is done." The tension is sharpest at the migration moment, when every record in your database is on the table.

Personal data touched by a typical migration includes: employee PAN, Aadhaar-linked payroll records, customer mobile numbers and email addresses collected for billing, KYC documents uploaded during vendor onboarding, and director identification stored for MCA filings.

A practical four-step DPDP migration review:

1. Classify personal data fields during the schema-mapping exercise. Tag every field containing a name, contact detail, national identifier, or biometric reference.
2. Check whether the DPDP purpose has ended. A former employee who left in FY 2021-22 is still within the eight-year Companies Act retention window — but the employment purpose that justified collecting their Aadhaar number ended at separation. Where the DPDP purpose has ended, anonymise rather than delete — replace the identifier with a tokenised reference that still satisfies tax-audit requirements without holding the original personal data.
3. Do not migrate unconsented marketing data. Customer contact details collected before a valid DPDP consent mechanism was in place should not move to the new CRM. Either obtain fresh consent before migration or exclude the field.
4. Document every decision — retain (with statutory basis), anonymise, or delete. This becomes your DPDP erasure log and demonstrates good-faith compliance if a Data Protection Board inquiry arises later.

MCA V3 and Statutory Filing History: What Must Survive the Cutover

The transition from MCA21 V2 to MCA V3 has already required companies to reconcile filing histories, re-download documents, and revalidate digital signatures. Running a system migration simultaneously adds compounding risk.

Filing history that must survive intact for eight years includes: board resolutions, annual returns (MGT-7 or MGT-7A), financial statements (AOC-4 and AOC-4 CFS), charge documents (CHG-1, CHG-4, CHG-9), and director KYC records (DIR-3 KYC).

Practical step before cutover: Export a consolidated PDF/A archive of all MCA filings from the V3 portal for the past eight financial years. Record the SHA-256 hash of each document. Store the archive in an immutable document management system that your new ERP can access on day one. Do not rely on future access to the MCA V3 portal — portal interfaces change; your obligation to produce the document does not.

Building a Defensible Migration Audit Trail

Every Indian migration should produce a single sign-off package that the statutory auditor can review without requesting additional evidence. Build it progressively through the lifecycle — assembling it retrospectively after go-live is painful, incomplete, and unconvincing.

The package must contain:

• Pre-migration record counts by table: e.g., "GL: 2,84,619 records; AP: 48,230 records; Fixed Assets: 1,247 records"
• Post-migration record counts with a variance report — any drop from pre-migration counts requires a named explanation and CFO approval
• GL closing-balance reconciliation by major head, signed by the CFO: opening balance in legacy = opening balance in new system
• Sub-ledger reconciliation reports: AR ageing, AP ageing, GST ITC ledger, TDS payable, fixed-asset gross block and accumulated depreciation
• Dropped/archived records log: every excluded record with documented reason — e.g., "12 vendor records with zero balance and no transactions since FY 2015-16 — archived to read-only store under SHA-256 sealed export; not purged because within eight-year retention window"
• Transformation log: every field-level conversion rule applied, with sample source and target values
• Exception log: every record that failed validation during mock loads, and how each was resolved before go-live
• Named approvals: CFO, Head of Tax, IT Project Manager — and a formal notification (not necessarily approval) to the statutory auditor

This package is also what you produce if the company faces a GST audit or an Income Tax scrutiny notice in the three to five years following migration.

Choosing Between Big Bang, Phased and Parallel Migration

Big bang migrates everything in a single weekend cutover. It suits companies with low transaction volumes, few integrations, and teams that have completed at least three clean mock cutovers. For most mid-market Indian businesses, a failed big-bang migration across a GST month-end produces unrecoverable reconciliation gaps — do not attempt it without a tested rollback plan.

Phased migration moves modules sequentially over weeks or months. A practical sequence for Indian mid-market businesses: accounts payable first (lowest compliance risk), then accounts receivable and billing, then inventory and manufacturing, then the general ledger and financial close. This approach extends the timeline but isolates risk to one module at a time and keeps the rest of the business running on the proven legacy system.

Parallel migration runs both old and new systems simultaneously through one or two full month-end closes. It is the most expensive approach — dual licensing, dual data entry, dual reconciliation — but the most defensible from a statutory audit standpoint. If your audit committee or lenders require it, two parallel months is the right default.

Timing guidance for India, FY 2026-27: Avoid cutovers in March (financial year-end), June (Q1 advance tax and GST return period), September (TDS and second advance-tax instalment), and December (Q3 returns). October and November are the lowest-risk cutover months in the Indian compliance calendar. The August–September advance tax cycle has closed, the GST September annual return reconciliation is past, and Q3 deadlines are still weeks away.

Worked Example: Manufacturer Migrating from Tally Prime to SAP S/4HANA

Scenario: ABC Fabrications Pvt Ltd — a precision-components manufacturer in Pune — has FY 2025-26 turnover of Rs. 82 crore and GST registrations in Maharashtra and Gujarat. The board approves a migration from Tally Prime to SAP S/4HANA Cloud with a go-live target of 1 November 2025.

What the first mock load revealed

The team migrated the vendor master directly from Tally without first validating GSTINs. Of 1,340 vendor records, 73 carried cancelled or surrendered GSTINs. These vendors had been used to claim ITC of Rs. 14,60,000 across FY 2023-24 and FY 2024-25. Had those records gone live in SAP unchanged, GSTR-2B auto-populated data would have shown no matching supplier returns for those GSTINs — creating ineligible ITC that must be reversed under Rule 37A of the CGST Rules 2017, with interest at 18% per annum on the reversed amount from the date of availment to the date of reversal.

How mock load 2 fixed it

The compliance team ran a bulk GSTIN validation via the GST portal's public API. Stale GSTINs were flagged. On review: Rs. 9,20,000 of the ITC had been claimed from vendors whose registrations had been cancelled for non-filing — this ITC was reversed in Tally before the cutover date and included in the GSTR-3B for October 2025. The remaining Rs. 5,40,000 related to vendors who had migrated to new GSTINs after cancelling old ones — the correct GSTINs were updated in the master, and the ITC was retained.

The cutover and first month-end close

The cutover was executed at midnight on 31 October 2025, after October's GSTR-3B was filed. The Electronic Credit Ledger on the GST portal showed Rs. 1,12,84,310 as the closing ITC balance. The identical figure was posted as the SAP opening entry. The CFO and the GST consultant co-signed a one-page balance confirmation, which was filed in the migration sign-off package.

During the November 2025 close, the team discovered that SAP had loaded the fixed-asset Written Down Value (WDV) for income-tax purposes using the accounting depreciation rate rather than the rate specified under the Income Tax Act 1961, Section 32 read with Appendix I. The result: the income-tax WDV block was understated by Rs. 2,10,000, which would have produced an overstated depreciation claim in AY 2026-27 — creating a potential addition under Section 143(3) scrutiny and interest exposure under Section 234B at 1% per month on the additional tax demand.

The depreciation schedule was corrected before the December advance-tax computation and before the ITR was filed. The migration sign-off package was updated to document the error and its resolution.

Key lesson from this example: The income-tax depreciation block and the accounting depreciation block are two separate data sets — one governed by Schedule II to the Companies Act and the other by Appendix I to the Income Tax Act. Both must be migrated and reconciled independently as part of the fixed-asset data-migration workstream.

Common Mistakes That Derail Indian Migrations

1. Purging "inactive" records without checking statutory windows. A vendor with no transactions since FY 2019-20 is still inside the eight-year Companies Act retention window until FY 2027-28. Archive it to a read-only store; do not delete.

2. Changing document numbering series at go-live without retaining the legacy series. Tax officers cross-reference IRNs in GSTR-1 against e-invoice data on the IRP. If the document number in SAP does not match the IRN metadata from the legacy Tally period, the reconciliation breaks under scrutiny.

3. Scheduling the cutover across a GST return due date. GSTR-3B for the cutover month will require data from two systems. If the new system is not live in time and the old system has been decommissioned, the return will be late. Under CGST Section 47, late fees run at Rs. 50 per day per return for nil returns (Rs. 25 CGST + Rs. 25 SGST) and Rs. 100 per day for other returns (Rs. 50 CGST + Rs. 50 SGST), subject to a ceiling of 0.04% of turnover in the state per return.

4. Not testing segregation-of-duties controls before go-live. SA 315 (Revised 2021) requires auditors to assess IT access controls. An ERP where a single user ID can create a vendor master, post a purchase invoice, and approve a payment runs directly into the auditor's IT general-controls finding. User-access design is a migration deliverable, not a post-go-live task.

5. Treating migration as complete at go-live. The project closes when the first statutory audit after the migration has reviewed and accepted the IT general-controls documentation. Keep the sign-off package live and accessible until that review is complete.

6. Migrating payroll mid-year without carrying forward year-to-date TDS. Payroll systems carry month-to-date and year-to-date figures for TDS under Section 192. A mid-year payroll migration that resets YTD counters will produce an incorrect Form 16 at year-end, generating mismatches in the employee's AIS on the Income Tax portal — and employee complaints that go directly to HR leadership.

Key Takeaways

• Migration is a compliance project: Section 128 of the Companies Act 2013 mandates eight-year retention; Section 36 of the CGST Act mandates six years. Both apply to every record in scope.
• Validate before you migrate, not after: GSTIN validation, PAN format checks, HSN/SAC code standardisation, and IRN linkage verification must be completed during mock loads — fixing them post-go-live under live transaction pressure is far more expensive.
• The DPDP Act and retention law pull in opposite directions: Classify personal data fields during schema mapping; anonymise data whose DPDP purpose has ended, rather than migrating it unchecked into the new system.
• Build the audit trail as you go: Pre- and post-migration record counts, GL reconciliation, sub-ledger reconciliation, transformation logs, and exception logs must be assembled in a single package for your statutory auditor's SA 315 review — not reconstructed after the fact.
• Avoid March, June, September and December cutovers: October and November are the lowest-risk months in the Indian compliance calendar. Align your migration window to the regulatory calendar from day one of project planning.
• Income-tax WDV and accounting WDV are separate data sets: Both must be migrated and independently reconciled — a missed step that frequently surfaces as a tax adjustment or advance-tax shortfall in the first post-migration year.
• Parallel close is the safest default: Two full month-end closes with both systems running, daily reconciliation, and named issue owners gives your audit committee, your lenders, and your statutory auditor the confidence that the migration has been executed with the discipline a regulated financial record-keeping obligation demands.