Legacy application modernization services, security and the DPDP Act: a compliance checklist
How do you keep a legacy application modernization programme compliant with India's DPDP Act?
A modernisation programme is DPDP compliant when every copy of personal data it creates is inventoried, minimised, encrypted, retained on a clock and logged. The Act does not regulate your architecture; it regulates what happens to personal data while you move it, which is exactly what modernisation does at scale.
A modernisation programme meets India's Digital Personal Data Protection Act when every copy of personal data it creates is inventoried, minimised, encrypted, retained on a defined clock and logged. The Act regulates what happens to personal data, not your architecture, and legacy application modernization services move more personal data in six months than the original system moved in a decade.
This checklist covers the obligations that actually bite during a migration, the control for each one, what compliance adds to budget and schedule, and the three places where personal data quietly escapes while a programme is running.
What the DPDP Act requires of a programme, not just a product
The Digital Personal Data Protection Act, 2023 makes the organisation that decides why and how personal data is processed the Data Fiduciary, and it holds that fiduciary responsible for the acts of any processor it appoints. Your modernisation partner is a processor. That relationship has to exist on paper before the first extract runs, not after the first audit. The Ministry of Electronics and Information Technology publishes the Act and the subsequent rule-making on its data protection framework pages, which is the source to cite in an internal note rather than a vendor summary.
Four obligations matter disproportionately in a migration. Purpose limitation says data collected for one reason cannot quietly be reused for another, which is what happens when a twelve-year-old customer table is copied into a shiny analytics warehouse because it was easier than filtering it. Storage limitation says data must be erased when the purpose is served, which is what a legacy database with no retention policy has never done. Security safeguards are mandatory, and a breach is notifiable. And the right to erasure has to be technically executable, which it usually is not in a system with fourteen denormalised copies of a customer record.
Note what the Act does not say. It does not mandate general data localisation for every business; it allows the government to restrict transfers to specified countries. The practical consequence for legacy application modernization services data residency decisions is that you should know and be able to prove where each dataset physically sits, rather than assuming a blanket India-only rule. Our longer treatment of the statute is in DPDP Act 2023 and AI: what Indian companies must do.
Where legacy systems break the rules, and the control that fixes each
Most findings in a modernisation audit are not exotic. They are the same six failures, and each has a standard control.
| DPDP obligation | How a legacy migration breaks it | Control we build in |
|---|---|---|
| Purpose limitation | Full table copies land in a new warehouse because filtering was harder | Field-level migration manifest; every column mapped to a stated purpose or dropped |
| Data minimisation | Test and UAT environments get a production clone | Masked, subsetted refresh pipeline; production clones forbidden by policy and by network rule |
| Storage limitation | Old system had no retention clock, so neither does the new one | Retention policy per entity, enforced by a scheduled purge job with its own audit record |
| Security safeguards | Credentials in config files, flat network, no encryption at rest | Secrets manager, TLS in transit, encryption at rest, network segmentation between old and new |
| Right to erasure and correction | Fourteen denormalised copies of a customer, none authoritative | Single system of record per entity, with downstream copies keyed and erasable by that record |
| Processor accountability | Offshore team has standing production access for the whole programme | Named roles, time-boxed just-in-time access, every session logged and reviewed weekly |
The middle column is not hypothetical. It is what an onboarding audit turns up on almost every fifteen-year-old system, which is why we start with one rather than with a design. The method is described in taking over a system you didn't build.
Seven controls to put in the statement of work
Compliance that lives in a policy document does not survive a go-live weekend. These seven belong in the contract and in the sprint plan.
- A data inventory before the architecture. Every table, file store, log sink and report that holds personal data, with owner, purpose, lawful basis and retention period. If this does not exist, the programme starts here.
- A migration manifest, column by column. Each field is carried, transformed, masked or dropped, and the decision is recorded. Anything unmapped fails the migration run rather than passing silently.
- Non-production data policy. Development, test and UAT environments receive masked subsets. This one control removes the largest share of accidental exposure in enterprise programmes.
- Encryption and key custody. Encryption at rest and in transit is table stakes; who holds the keys, and whether the processor can decrypt without you, is the question that actually matters.
- Access that expires. Just-in-time, role-scoped, time-boxed production access with session logging. Role-scoped means the role, not the person, defines the reachable data.
- An audit trail that a regulator can read. Who accessed which record, when, and under what change ticket. Retained beyond the programme, not deleted with the project environment.
- A breach runbook with named humans. Detection, containment, assessment and notification, rehearsed once before cutover rather than improvised after it.
What does DPDP compliance add to the cost and timeline?
Between eight and fifteen per cent of programme effort, and it is cheaper when it is designed in than when it is retrofitted. Our Legacy-to-AI Modernization Program runs from $31,500 or ₹22,40,000 and reaches $105,000 or ₹72,00,000 and above for multi-system estates; the controls above are inside that scope, not a line item bolted on top. Where the estate is unmapped, a ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build, produces the data inventory and the residency decision before anyone commits to a number. Published starting prices for every programme are on the pricing page.
After go-live, the obligations do not stop. Retention jobs have to keep running, patches have to land, and access reviews have to happen on a cadence. A Software Maintenance and Support Care Plan covers that from $1,000 or ₹68,000 a month on Essential, $2,500 or ₹1,60,000 on Standard with four-hour response, and $5,250 or ₹3,40,000 on Enterprise with one-hour response and a named engineer.
Three places personal data escapes during a modernisation
Migration dry runs
Teams rehearse the cutover four or five times, and each rehearsal leaves a full copy of production somewhere: a staging bucket, an engineer's laptop, a shared drive, a ticket attachment. Every dry run must write to a single named location with a delete date, and the deletion must be verified rather than assumed. This is the single most common finding we raise on inherited programmes.
Integration middleware and its logs
Message queues, integration platforms and API gateways log payloads by default to help debugging. Those logs hold PAN numbers, phone numbers and addresses, and they are usually retained longer than the data in the database. Redact at the boundary, before the log line is written, and check the retention of every sink.
The parallel-running window
During parallel running the old system and the new one both hold live personal data, and erasure or correction requests have to be honoured in both. Build the dual-write and dual-delete path before parallel running starts. Teams that skip this discover, weeks later, that they have been quietly rebuilding records a customer asked them to remove.
When a compliance-led modernisation is the wrong choice
If your system holds almost no personal data, for example a plant-floor scheduling tool or an internal pricing engine, a DPDP-driven programme is overhead. Modernise for maintainability instead and keep the compliance work proportionate.
If a regulator has already issued a directive with a deadline, a phased strangler-pattern programme may be too slow, and a contained replacement of the offending component is the honest answer. And if the pressure to modernise is coming from a sales team who want a new interface rather than from risk or engineering, the correct advice is to defer: a compliance programme with no operational owner will stall at the first access review. We would rather say that in the first call than in month four. The trade-off between approaches is argued in a rewrite vs incremental modernisation.
What this looks like on a real programme
A university ran a fifteen-year-old ERP holding student records, fee data and staff payroll. The compliance exposure was not the application; it was the nineteen reporting extracts that departments had built over a decade, each one a spreadsheet of personal data on a shared drive with no owner. We inventoried them first, replaced fourteen with permission-aware reports against a single system of record, and killed the other five. The application work followed a strangler pattern so that no module was rewritten wholesale, described in modernising a fifteen-year-old university ERP. The lesson generalises: the leak is rarely in the system you are replacing.
Checklist before the first data extract
- Data inventory signed off by a named owner, covering databases, files, logs and reports
- Processor agreement executed, with sub-processors listed and residency stated per dataset
- Retention period agreed per entity, with the purge mechanism identified
- Non-production masking pipeline built and tested before any environment is refreshed
- Production access model defined: roles, approval path, expiry, session logging
- Erasure and correction path proven end to end, including downstream copies
- Breach runbook written, with detection thresholds and a rehearsal booked
- Dry-run artefacts assigned a storage location and a deletion date
Related reading
Legacy application modernization services: a practical implementation guide covers the delivery sequence, data migration for platform implementations covers cleansing before the move, and AI audit trails: what regulators will ask to see covers evidence. If you want a residency and retention position reviewed against your estate, talk to us.
Treat DPDP as a constraint on the migration plan rather than a document produced at the end, and the compliance work stops being the thing that delays go-live.
Frequently asked questions
Does the DPDP Act require legacy data to stay in India?
▾
Not as a blanket rule. The Act permits the central government to restrict transfers to specified countries rather than mandating general localisation. Sector regulators such as the RBI impose stricter residency rules of their own. The practical requirement is to know and evidence where each dataset sits, per system and per backup.
Who is responsible if a modernisation vendor causes a data breach?
▾
The Data Fiduciary, meaning your organisation, remains accountable to the regulator and to affected individuals. The processor is bound by contract. That is why the processor agreement, sub-processor list, access model and breach notification timelines must be executed before any production extract runs.
How much does DPDP compliance add to a modernisation budget?
▾
Typically eight to fifteen per cent of programme effort when designed in from the start, and considerably more when retrofitted after go-live. Eazyware includes the inventory, masking pipeline, access model and audit trail inside the Legacy-to-AI Modernization Program, which starts at $31,500 or ₹22,40,000.