Every migration practice already has a practice management system. For many it is a spreadsheet, a shared drive, an inbox and the agent's memory. This guide answers what a purpose-built system does instead, which parts of it a compliant Australian practice actually needs, how the pricing models differ, and how to choose and roll one out without losing a file.
What migration practice management software is
Migration practice management software is a case management system built around the way a visa matter runs in Australia. One file holds the client, the applicants and any sponsor; a subclass-specific checklist and questionnaire collect the evidence; deadlines are tied to Department and Tribunal timeframes; the service agreement, invoices and clients' account follow the Code of Conduct; and the lodgment itself happens in ImmiAccount with the file open beside it. It is used by registered migration agents, by legal practitioners who give immigration assistance, and by the admin and paralegal staff who do most of the data entry in either kind of practice.
Three terms get used interchangeably and should not be:
- A CRM (customer relationship management system) tracks enquiries, contacts and follow-ups. It is built for sales, measures conversion, and knows nothing about a visa.
- Case management software manages matters through stages, with documents, tasks and deadlines attached. Generic legal case management does this well for litigation and conveyancing; it has no idea what a subclass 482 nomination needs.
- Practice management software adds the business layer: agreements, invoicing, trust or clients' accounts, reporting, staff permissions and compliance records. Migration practice management software is the subset that understands Australian visa work natively.
Most purpose-built migration platforms, LodgeHQ among them, are all three at once. Our comparison of CRMs for migration agents covers why a generic CRM tends to fail the second and third tests.
The thirteen modules a compliant practice needs
The Code of Conduct, the Migration Act and the Privacy Act between them dictate most of what the software has to do. Below, each module is paired with the obligation it serves, so a feature list can be read as a compliance map rather than a brochure.
1. Clients, applicants, sponsors and conflicts
A matter is rarely one person. The system must hold the client, every applicant, the sponsor or nominator and any third-party payer as separate parties with defined roles, because the Code's duties run to the client and the duty of confidentiality (section 35) does not evaporate because a sponsor is paying. Identity verification before assistance begins (section 36) and a conflict check at intake both need a record on the file. Our conflict-check workflow and who-is-the-client guide go deeper.
2. Matters, stages and subclass workflows
Each matter carries a subclass, a stage and a checklist of what that subclass needs. The checklist is the difference between migration software and generic case management: it should be specific enough to know that a partner application needs relationship evidence in four categories and an employer-sponsored one needs a nomination, and flexible enough for a practice to add its own items. Our document checklist guide shows what a good one contains.
3. Questionnaires, document collection and the client portal
Facts should be typed once, by the person who knows them. A subclass-aware questionnaire completed by the client in a secure portal produces structured data that drives the checklist, pre-fills Department forms and feeds ImmiAccount auto-fill. The portal also replaces email attachments as the channel for evidence, which matters under Australian Privacy Principle 11. See reducing document chasing, moving clients onto a portal and email attachments versus portals.
4. Deadlines and the Department's clock
Section 33 of the Code requires an agent to be aware of the times by which things must be done and the consequences of missing them. The software should derive deadlines from the matter (visa expiry, bridging visa dates, response-to-request dates, Tribunal lodgment windows) rather than rely on someone typing them into a calendar, and escalate when a deadline is close with no recorded action. Our guides on deadline management and ART review deadlines set out the mechanics.
5. Service agreements, fees and invoicing
A written service agreement before assistance is given (section 42), fees that are fair and reasonable (section 46), disclosure of likely disbursements (section 47), a refund policy (section 52), an invoice before any charge with a receipt after payment (section 49), and written notice when the agreement is varied (section 44): all of it has to be produced, signed, stored and kept current. Section 313 of the Migration Act adds that an agent is not entitled to be paid unless the client has been given a statement of services. Template-driven agreements that pull the parties, fees and disbursements from the matter, built-in e-signature, and invoicing that respects the blocks of work in the agreement are the practical answer. See blocks of work, statements of services and invoicing and updating agreements when scope changes.
6. The clients' account
Money received before it is earned, and amounts received for disbursements, belong in a clients' account, and section 50 of the Code restricts what may be paid into and out of it. A ledger per client, receipts and payments tied to invoices and matters, and a monthly reconciliation you can produce on request are the minimum. Spreadsheets fail this test the first time two people post to them. Our trust accounting guide and monthly reconciliation walkthrough cover the detail.
7. Documents, letters and Department forms
Letters, submissions and the Department's own PDF forms (Form 956 appointments, Form 80 and 1221 particulars, bridging visa applications and the rest) should generate from matter data rather than be retyped. The file should keep one version of each lodged document, with PDF tools (merge, compress, split) applied in place rather than on someone's desktop.
8. Lodgment and ImmiAccount
Lodgment happens in the Department's system, not yours, so the question is how the two connect. Prefilling ImmiAccount from verified questionnaire data removes the second round of typing and the transposition errors that come with it, provided the agent reviews every page and lodges personally. Our guides to ImmiAccount auto-fill and organisation ImmiAccounts and team workflow cover both halves.
9. Communication on the file
OMARA's guidance on practice management duties expects client contact to be recorded on the file. That is only realistic if email, SMS, WhatsApp and portal messages are captured against the matter automatically rather than forwarded by hand. Oral communications need a contemporaneous file note (section 55); the software should make writing one a ten-second act from wherever the call was taken. See file notes that satisfy auditors.
10. Compliance records and the audit trail
Consumer guide given before assistance (section 38), identity verified (section 36), conflicts checked, knowledge and skills maintained (section 22), material developments advised promptly (section 39), and every action on the file logged with who did it and when. An audit trail you cannot edit is what turns "we always do that" into evidence. Our audit trail guide lists what the log should contain, and the OMARA compliance checklist ties the obligations together.
11. Staff, permissions and supervision
Section 23 of the Code requires reasonable steps to ensure no member of the business contravenes it, which in software terms means role-based access, a visible record of who did what, and review steps before lodgment. See role-based access control, supervising practice staff and pre-lodgment quality assurance.
12. Security, privacy and data location
Client files are among the most sensitive personal information any small business holds: passports, relationship evidence, health and character material. APP 11 requires reasonable steps to protect it; APP 8 governs disclosure overseas, which includes hosting in another country. Ask where the data and documents are stored, whether the database is encrypted at rest, whether multi-factor authentication is enforced, how backups are tested and how a breach would be notified. Our Privacy Act security checklist, MFA guide, backup testing guide and breach response plan are the working documents.
13. Retention and exit
Client files must be kept for seven years after the last action on them, and a client is entitled to their documents when the engagement ends. The software has to make both easy: a closure process that fixes the retention date, and an export that gives you every matter, document and record in open formats without asking the vendor. If a platform cannot show you the export during the trial, assume it does not exist. See file retention and ending an engagement.
How the pricing models differ
Vendors price in four broad ways, and the differences matter more than the headline number.
- Per user or per licence. Every login pays, including the paralegal who only uploads documents. Cheap for a sole practitioner, expensive for a practice of six.
- Per registered agent, with staff included. The price follows the number of agents whose names go on the Form 956, and support staff are free. This is LodgeHQ's model: A$99 a month plus GST per registered agent, with unlimited admin and support staff.
- Per firm, flat. One price regardless of headcount, usually with tiers that cap matters or storage.
- Modular. A base price plus paid modules: e-signature envelopes, SMS, extra storage, client portal, trust accounting. The total is only knowable after you list the modules you need.
Three more lines belong in any comparison: onboarding or implementation fees, the cost of importing your existing data, and the standalone subscriptions the platform lets you cancel. Our pricing of five common standalone tools shows that the last line is often larger than the subscription itself, and what migration agents charge puts the software cost against practice revenue.
Spreadsheets, generic tools or purpose-built
A spreadsheet-and-shared-drive practice works until the second staff member, the first missed deadline or the first OMARA request for a file. A generic legal or sales system works until the first trust reconciliation or the first subclass whose checklist nobody built. Purpose-built software is justified the moment any of three things is true: more than one person touches the files, the practice holds client money before it is earned, or the agent cannot personally remember every deadline. For most registered practices that is day one. Why agents are switching covers the pattern we see most often, and how to start a migration agency covers setting up properly from the beginning.
How to evaluate a platform
Run a trial as a rehearsal of a real matter, not a tour of the features.
- Take one real matter from enquiry to lodgment. Enquiry, conflict check, consultation note, agreement, questionnaire, documents, forms, invoice, clients' account entry, ImmiAccount. Anything that forces you out of the system is a cost you will pay every week.
- Test the exits. Export everything on day two of the trial and open the files. Then ask how your current data gets in, who does the import and what it costs.
- Ask the security questions in writing. Where is it hosted; is the database encrypted at rest; is MFA enforced; who at the vendor can see client data; how are backups tested; what is the breach notification commitment. Keep the answers with your Privacy Act records.
- Map the features to the Code. Use the thirteen modules above as the checklist. A missing clients' account ledger or audit trail is not a gap to work around; it is a reason to stop.
- Time the support. Send one real question and measure the answer. Support during a trial is the best it will ever be.
- Price the true total for your headcount. Licences, onboarding, import and add-ons, minus the subscriptions you can cancel, over a year.
Our shortlist of the best case management software for migration agents applies this method to the platforms available in Australia.
Rolling it out without losing a file
Import the open matters first, with the data checked by the person who knows them; run the old and new systems in parallel for a billing cycle; write the standard operating procedures as you go rather than afterwards; and set a cutover date after which nothing new is created in the old system. Our guides to building a living playbook and growing from solo to a team cover the people side, which is where rollouts actually fail.
Where LodgeHQ fits
LodgeHQ is migration practice management software built in Australia by a registered migration agent, Awais Nisar (MARN 2318017), for his own practice first. It covers the thirteen modules above in one subscription: clients, applicants and sponsors on one matter; subclass-aware checklists and questionnaires; a client portal; deadline tracking; template-driven agreements with built-in e-signature; invoicing and a clients' account ledger; letters and 37 Department PDF forms plus the ART's MR5; the eLodge Chrome extension for ImmiAccount auto-fill; email, SMS, WhatsApp and portal messages on the file; an audit trail; role-based access; and a full data export you can run yourself at any time. Hosting, database, document storage and AI run on Amazon Web Services in Sydney. The price is A$99 a month plus GST per registered agent with unlimited support staff, and there is a 14-day free trial with no credit card required.
The bottom line
Migration practice management software is not a CRM with a visa field added. It is the system of record for a regulated professional practice, and the Code of Conduct is effectively its specification. Choose by rehearsing a real matter, by testing the exits and by mapping features to obligations; price it on your real headcount after the subscriptions it replaces; and roll it out with the people who will use it every day.