Do QGIS and ArcGIS use the same coordinate transformation engine?

No. QGIS uses the open-source PROJ library, the same engine behind GDAL and PostGIS. ArcGIS Pro uses Esri's own projection engine with its proprietary transformation grids. They share most EPSG definitions but can pick different default transformation paths.

Which handles datum transformations more transparently, QGIS or ArcGIS?

QGIS exposes the PROJ pipeline explicitly, showing the operation string and accuracy estimate, and lets you choose between candidate transformations. ArcGIS Pro also lists geographic transformations but the default selection is more automatic, which is convenient but easier to accept without checking.

Why do QGIS and ArcGIS sometimes give slightly different reprojected coordinates?

Because they may apply different datum transformations or grid-shift files. A null transformation versus a NTv2 grid shift can differ by a metre or more. Pin the same EPSG transformation code in both tools to get matching results.

Which tool is better for CRS-critical survey work?

Either works if you control the transformation explicitly. QGIS gives finer visible control over the PROJ pipeline and accuracy; ArcGIS Pro integrates well with published Esri datums and enterprise data. The deciding factor is whether you verify the transformation, not the brand.

QGIS vs ArcGIS for Coordinate Systems

The short answer

The real difference between QGIS and ArcGIS for coordinate systems is the engine underneath. QGIS reprojects through PROJ, the open-source library that also powers GDAL, PostGIS, and most of the FOSS4G stack. ArcGIS Pro uses Esri's own projection engine with proprietary geographic (datum) transformation grids. Both read the EPSG registry, both will happily display layers in mixed CRS on the fly, and both produce correct results when you control the transformation. They diverge in how visible and how automatic the datum transformation is — and that, not the projection math, is where accuracy is won or lost.

Projection vs datum transformation

Reprojecting between coordinate systems is two operations, and conflating them causes most CRS confusion.

The map projection converts geodetic latitude/longitude to planar X/Y (Transverse Mercator, Lambert Conformal Conic, and so on). This is deterministic and identical in both tools to floating-point precision.
The datum transformation moves coordinates between different geodetic datums — NAD27 to NAD83, NAD83 to WGS84, ED50 to ETRS89. This is not unique. There are usually several published transformations between any two datums, ranging from a crude 3-parameter shift (good to several metres) to a NTv2 or grid-based shift (good to centimetres). The number you get depends on which transformation is applied.

Where QGIS and ArcGIS disagree, it is almost always step 2. The projection is the same; the chosen datum transformation is not.

How QGIS handles CRS (the PROJ pipeline)

QGIS surfaces PROJ directly. When you reproject and more than one transformation exists, QGIS opens a "Select Transformation" dialog listing each candidate as a full PROJ pipeline string with an accuracy estimate in metres and the area of use. You see, for example, a +proj=hgridshift +grids=us_noaa_... operation versus a null transform, and you choose. The selection is stored per project, so it is auditable.

Practically:

EPSG:4267 (NAD27) to EPSG:4269 (NAD83) offers the NADCON grid shift; PROJ will use it if the grid file is installed, and warn you if it is missing and falls back to a less accurate path.
You can inspect the exact operation with the command line: projinfo -s EPSG:4267 -t EPSG:4269 -o PROJ lists candidate operations and accuracies.
Because GDAL and PostGIS use the same PROJ, a gdalwarp -s_srs EPSG:4267 -t_srs EPSG:4269 -ct "<pipeline>" or a PostGIS ST_Transform will match QGIS exactly when the same pipeline is pinned.

The strength here is consistency across the open stack and total visibility of what was applied. The weakness is that missing grid files silently degrade accuracy unless you read the warning.

How ArcGIS Pro handles CRS

ArcGIS Pro uses Esri's engine and its own transformation catalogue, with grid files shipped as part of the install (the pe_... data). When source and target datums differ, Pro picks a default geographic transformation and lists alternatives under Map Properties → Transformation or in the Project tool's environment. Esri publishes transformation accuracy values too, but the default is applied more automatically — convenient, and the usual reason a Pro user never realises a transformation occurred at all.

Pro's advantages: tight integration with Esri-published datums (including national grids), a curated default that is usually sensible, and consistency across an enterprise geodatabase where the spatial reference is enforced at the feature-class level. Its risk: the automatic default makes it easy to accept a transformation without examining it, and Esri's proprietary grids are not bit-identical to PROJ's for every datum pair.

Why the same data reprojects to two slightly different places

A concrete example: reproject a UK point from EPSG:4326 (WGS84) to EPSG:27700 (OSGB36 / British National Grid).

If WGS84→OSGB36 uses the OSTN15 NTv2 grid, you get the official sub-metre result.
If it uses a 7-parameter Helmert approximation, you can be off by up to ~2 m in parts of the UK.

QGIS will ask which one (and you should choose the OSTN15 grid, EPSG transformation code 7709). ArcGIS Pro defaults to a sensible transformation but verify it is the grid-based one, not the approximate Helmert. Pin the same EPSG transformation code in both tools and the outputs converge. This is the actionable rule: matching coordinates require matching transformations, not matching software.

A reproducibility workflow that survives both tools

Record the source CRS and the target CRS as EPSG codes in project notes.
Identify all candidate datum transformations: projinfo -s <src> -t <dst> in QGIS/PROJ, or the transformation list in ArcGIS Pro.
Choose the highest-accuracy transformation valid for your area of interest (prefer NTv2/NADCON grids over Helmert).
Confirm the required grid-shift files are installed in both environments.
Reproject a known control point in both tools and compare. Sub-millimetre agreement means the same pipeline; a metre-scale gap means different transformations.
Store the chosen EPSG transformation code with the deliverable so the next analyst reproduces it exactly.

Common pitfalls and why they happen

Assuming WGS84 and NAD83/ETRS89 are interchangeable. They were within a metre in the 1980s but have drifted; a null transformation now introduces over a metre of error in some regions. Both tools may default to null.
Missing PROJ grid files in QGIS. Without the grid, PROJ falls back to an approximate transform and only warns in the message log, which is easy to miss.
Trusting the ArcGIS default silently. It is usually right, but for legacy datums and national grids confirm the chosen transformation.
Comparing coordinates from the two tools without pinning the transformation. The discrepancy is the transformation, not a bug.
Editing data in a geographic CRS and measuring in it. Display tolerance is fine; analysis is not — reproject to a suitable projected CRS first.

Validation

After any reprojection, test a control point with published coordinates in both datums (national survey monuments are ideal). Confirm the residual matches the transformation's stated accuracy. For raster, check that gdalinfo and the QGIS layer properties agree on the CRS WKT, and that ArcGIS reports the same authority code. If a deliverable will move between FOSS and Esri stacks, run the control point through both before committing.

Bathyl perspective

We treat the choice of QGIS or ArcGIS as secondary to controlling the datum transformation. Our practice is to pin an explicit EPSG transformation code, verify it against a control point, and record it with the data so results are identical regardless of which engine opens the file next.