An Australian organisation replacing a legacy application needs an answer to a deceptively simple question: which information should move into the new system? Copying every field preserves old assumptions, unnecessary records and access arrangements that may no longer fit the business.
A better software modernisation brief treats data decisions as deliverables. It identifies what remains operational, what needs controlled retention and what can be removed after the appropriate review. The result should help the business operate the replacement without leaving forgotten copies scattered through test systems and supplier accounts.
Start the privacy discussion while scope can still change
The OAIC's privacy impact assessment guide describes assessing how a project affects individuals and identifying measures to address those effects. Its scope includes changes to systems, databases and information storage. This makes it relevant to a migration, even when the replacement looks similar to users.
Use the assessment to inform engineering decisions. Your organisation's privacy lead should establish applicable requirements and exceptions. This article does not assume that every Australian business has identical obligations, or that purchasing an Australian cloud region answers every privacy question.
Build an inventory people can make decisions from
An inventory should connect data to a purpose, owner and workflow. A list of database tables alone rarely tells a product owner whether a historical field is still needed.
- ▸Identify the information collected and where it originates.
- ▸Name the team using it and the purpose it currently serves.
- ▸Record systems, exports and suppliers that receive copies.
- ▸Identify access roles, retention decisions and correction processes.
- ▸Mark uncertain fields for a decision instead of silently migrating them.
Include attachments, logs, spreadsheets and scheduled exports. A carefully controlled new database can coexist with an old shared folder containing unrestricted copies. Ask the vendor to discover these surrounding flows as part of the assessment, with an agreed limit on the systems it will examine.
Separate migrate, retain and retire
For each meaningful group of records, choose a proposed treatment. Some records support current operations and should migrate. Others may require a controlled archive rather than appearing in the everyday application. Some may be candidates for removal once the business confirms its retention and legal requirements.
Record who makes that decision. The developer should not invent a retention period because a storage setting needs a number. Equally, leaving every decision unresolved until cutover encourages indiscriminate copying.
The OAIC's guide to securing personal information discusses protecting personal information and managing information throughout its lifecycle. It also highlights security assessment of cloud providers and the possible relevance of other Australian Privacy Principles. Use that guidance with the people responsible for your organisation's actual obligations.
Give test environments their own data plan
Consider a fictional membership business replacing a booking platform. The source system contains active memberships, expired accounts and notes entered by staff over many years. The vendor asks for a complete database copy to develop the importer.
A better first step is to provide the schema and synthetic examples covering difficult cases: duplicate members, missing addresses, changed preferences and unusual booking histories. If a limited real-data sample is necessary, agree its purpose, access, protection and deletion separately.
Require the supplier to demonstrate that test fixtures cover important relationships without exposing unnecessary information. Removing a person's name while retaining a detailed combination of identifying attributes is not automatically sufficient. Have your privacy lead review the sample approach rather than treating a renamed column as proof of de-identification.
Test access and correction across connected systems
A migration can preserve the data while breaking the user's ability to manage it. Include tests for finding a record, correcting it and propagating an approved change to connected applications. Identify which system owns each field after the transition.
For example, if the new portal corrects a telephone number but the old CRM overwrites it during a nightly import, the migration has not established a reliable source of truth. Acceptance should include the next synchronization cycle, not just the immediate screen update.
Our CRM and ERP integration scope guide helps define ownership and reconciliation at these boundaries. Keep unresolved differences visible in a queue with a named decision owner.
Treat retirement as a separate work package
Turning off the old user interface does not remove its database, backups or supplier access. Ask for a retirement checklist that covers scheduled jobs, export destinations, service accounts, shared folders and disaster-recovery procedures.
Backups deserve an explicit decision. Define how retained copies are protected, when they expire and how an older restored backup will be prevented from silently reintroducing information that should no longer be active. Confirm the appropriate treatment with your records and privacy owners before promising deletion.
The final evidence should describe what was removed, what remains, why it remains and who controls it. This is more useful than a broad statement that the old environment has been cleaned up.
Make remote access reviewable
Remote development may involve overseas access even when hosting remains in Australia. Ask who can view production information, from which locations, through which tools and under which approved responsibilities. Evaluate these arrangements with the relevant privacy guidance and your advisers; geography alone does not settle the answer.
Agree Australian business-hour review windows and an escalation process for migration decisions. A supplier should be able to work with restricted examples and staged access rather than requiring unrestricted access throughout the project.
Buy a migration with clear decisions
Your request for proposal should include an inventory deliverable, disputed-data process, test-data approach, reconciliation evidence and retirement checklist. Use our quote comparison worksheet to check whether competing estimates include the same work.
TuniCyberLabs can discuss remote Custom Software Development for Australian buyers, including modernization and integration work. Send a sanitized outline of the legacy workflow, the systems involved and the decisions your team needs help making.