“Data Engineer” is a common technology job title, but occupation mapping for an ACS migration skills assessment depends on what the work actually does—not on the label printed in the employment contract. In a Database Administrator versus Data Engineer ACS comparison, distinguish responsibility for database availability, access and recovery from responsibility for building and maintaining data pipelines and analytical datasets.
The current ACS IT occupation pages list Database Administrator 262111 and a range of software, DevOps and data-science occupations. They do not present a standalone migration occupation called simply “Data Engineer.” That makes duty analysis essential.
The Database Administrator centre of gravity
ACS describes Database Administrator 262111 around planning, configuring, maintaining and supporting database management systems, with emphasis on database architecture, integrity, security, backup and recovery, documentation, upgrades, reliability and performance.
- database availability and performance tuning;
- backup, recovery and disaster-recovery procedures;
- access, integrity and security controls;
- database platform upgrades and operational testing;
- database administration standards and documentation.
The modern Data Engineer centre of gravity can be different
A Data Engineer may spend much more time building software and pipelines around data than administering the database platform itself. Typical work can include ingestion, ETL/ELT, transformation code, orchestration, streaming, data-quality automation, lake/lakehouse platforms, reusable services and deployment automation.
Cloud-heavy roles need the same function-first analysis; AWS cloud roles and ACS occupation mapping is a useful comparison.
A boundary test: what survives if the database product changes?
| If most of the work is… | The mapping question should investigate… |
|---|---|
| Operating and protecting database-management systems | Database Administrator 262111 |
| Building production data pipelines and software services | Software/developer occupations, depending on the actual engineering duties |
| Building/operating delivery automation around platforms | DevOps Engineer 261316 where the professional function genuinely matches |
| Statistical modelling, analytical methodology or data-science work | Relevant ACS data occupations, depending on actual duties |
This is not an automatic crosswalk. It is a way to identify which official occupation descriptions deserve closer testing against your real evidence.
Do not rewrite the career backwards from ANZSCO
Keep the employer’s real title and describe the real duties. A Data Engineer should not be retrospectively renamed “Database Administrator” just because a database appears in the architecture. Likewise, a DBA who occasionally writes an ETL script does not automatically become a software engineer.
Build a duty map before choosing the occupation
- List recurring responsibilities from the employment evidence—not just tools.
- Group them by professional function: database operations, software/pipeline engineering, DevOps/platform work, analytics/data science.
- Identify which group occupies the largest share of responsibility and decision-making.
- Compare that function with the current ACS occupation descriptions.
If more than one occupation still fits after that mapping, consider whether nominating up to three ACS occupations helps.
- Check whether the chosen occupation remains consistent across references, projects, payment evidence and career progression.
The right occupation is the one the evidence can explain truthfully and coherently. A broader Data Engineer mapping can test additional occupation families, but this comparison is deliberately limited to the DBA-versus-data-engineering boundary.
Occupation mapping is also separate from choosing between the RPL and General Skills Assessment pathways.
Two professionals, one database platform, different occupations
Imagine two employees working on the same cloud data warehouse. The first designs access policies, tunes workloads, manages backup and recovery, plans maintenance windows and owns operational reliability. The second writes ingestion services, develops transformation frameworks, orchestrates pipelines and maintains reusable code that moves data between systems. Their technology stack overlaps, but their professional outputs differ. The ACS occupation descriptions make the distinction important: Database Administrator 262111 centres on operating and maintaining database-management systems, while software and other ICT occupations describe different professional functions.
The label “Data Engineer” is especially ambiguous because employers use it for jobs ranging from database platform operations to production software engineering and analytical modelling. A candidate should therefore avoid deciding the occupation by searching for the closest title alone. Instead, examine recurring deliverables and the decisions that created them. Did the person primarily keep a database available, secure and recoverable, or build software that transforms and delivers data products? The answer should emerge from evidence rather than from a preferred visa strategy.
Follow the incident: a useful boundary case
Suppose a warehouse query becomes slow after a schema change. A DBA might investigate indexing, execution plans, resource contention, configuration and recovery risk. A data-pipeline engineer might inspect upstream ingestion, data skew, transformation logic, partitioning and code changes. Both could contribute to the fix. The occupation question is which responsibilities the applicant repeatedly owned across the employment period, not who happened to join one incident call. Record the sequence of decisions, the applicant’s authority and the resulting operational or engineering improvement.
Another boundary case is automated backup. Writing a small script to schedule backups does not necessarily make a database administrator a software engineer. Conversely, a developer who provisions a database as one component of a distributed application does not automatically become a DBA. Evaluate the whole role over time. The ACS assessment-process guidance explains that skills and experience are assessed against the nominated occupation and relevant professional standards, rather than by matching isolated technologies.
Translate a CV into evidence an assessor can test
For each role, construct a duty matrix with four columns: responsibility, evidence, frequency and decision authority. “Managed Snowflake” is not a sufficiently informative responsibility because it could mean permission administration, cost optimisation, SQL development, data modelling or orchestration. Replace it with an accurate description of what the person did: for example, “designed recovery procedures and tested restore objectives” or “implemented and maintained incremental ingestion pipelines with automated quality checks.” The purpose is clarity, not exaggeration.
Attach evidence at the right level. An employer reference should identify the role and its recurring duties; an architecture diagram can explain system context; a redacted design note can show technical reasoning; and independent payment records can corroborate remunerated employment. The ACS reference requirements specify the employer, dates, hours, salary, location, title and signed duty information expected. Do not submit a copied occupation description as though it were an authentic account of work. The reference must describe the person’s actual responsibilities.
When platform ownership and pipeline development are both substantial
Some roles genuinely combine database operations and data engineering. For example, a senior engineer might maintain a managed warehouse, implement disaster recovery and design an ingestion platform. The solution is not to erase half the job. Divide the work into periods and functions, identify the most substantial recurring professional responsibilities, and compare each plausible occupation against the full official description. A candidate with several roles across different years may need to distinguish early DBA duties from later software-oriented data engineering rather than collapsing the entire career into one generic paragraph.
Where more than one occupation appears plausible, the ACS application-process information explains that its portal can recommend codes based on the applicant’s skills. That recommendation is not permission to invent duties. If different codes are considered, the evidence for each must remain internally consistent. The strongest mapping is the one an assessor can understand from the employer’s account of the job, supported by verifiable technical examples.
Do not confuse an assessment pathway with an occupation
A separate decision concerns the appropriate ACS assessment pathway. Someone with a closely related ICT qualification may have a different evidence profile from an applicant relying on Recognition of Prior Learning. The ACS General Skills pathway outlines qualification, employment and optional certification evidence for that route. The existence of an RPL route does not change what Database Administrator 262111 means; it changes how the applicant demonstrates the required professional knowledge and experience. Occupation fit and pathway eligibility must both be established.
If RPL applies, technical examples should explain the applicant’s own problem solving. For a database-centred project, that might be designing a recovery architecture, assessing consistency risks or implementing a secure migration with rollback controls. For a pipeline-centred project, it might be choosing a change-data-capture strategy, handling late-arriving events or designing idempotent processing. Such examples can clarify the professional function, but a project written by someone else or based on an invented implementation would undermine the application.
Test a mixed-role claim against payment and time records
Applicants sometimes describe several simultaneous projects as though each represented full-time work. A more credible account shows the actual employment period, weekly hours, role changes and which duties belonged to which employer. The ACS experience-evidence guidance addresses professional-level remunerated work and the supporting documentation. If the person moved from database operations into data engineering within one employer, ask whether the reference can accurately show the dates and duties for each position rather than presenting a single undifferentiated title.
Payment records are not technical proof, and technical artefacts are not payment proof. Keep them distinct. A well-written portfolio may demonstrate skill but cannot, on its own, establish the paid employment period. A payroll record may establish remuneration but cannot, on its own, identify the nominated occupation. The evidentiary chain works only when these documents support the same truthful chronology.
The decision that should come before selecting a code
Write a one-paragraph explanation of what the applicant was employed to achieve, which systems they were accountable for and what technical decisions they personally made. Then remove every product name. If the description still clearly concerns database administration, that is evidence for testing the DBA occupation. If it mainly concerns building and operating software-based data pipelines, investigate the relevant engineering occupations instead. The Database Administrator vs Data Engineer ACS comparison is ultimately about professional responsibility, not whether the résumé includes SQL, Python, AWS or Azure.
Finally, ask the employer to review the factual description for accuracy and check the current ACS occupation list before filing. If the mapping is borderline, obtain qualified advice rather than adjusting historical duties to fit a preferred code. A consistent application should make sense to a reader who has never met the candidate, without relying on the job title as a shortcut.
