NVivo 15 Cross-Platform Collaboration: 2026 Project Delivery Checklist

A Windows NVivo project uses .nvp, while a Mac NVivo project uses .nvpx, according to NVivo’s documented project file types. That difference is enough to change your delivery plan.

Symptom: Everyone can open the project, but a query, media link, or analysis feature is missing at final review.
Fastest fix: Choose one master platform, align the main NVivo version, and complete a controlled cross-platform trial before formal coding.

This guide is for mixed Windows and Mac research teams, graduate students whose supervisors use another platform, cross-university projects, and higher-education staff responsible for deployment, archiving, or data security. It is also useful when your lab has no Mac but must validate a Mac-side delivery before a thesis deadline.

Last updated August 29, 2026. Version and workflow details were checked against the listed official NVivo documentation and the official NVivo 15.3 release notes. If a later major version, project format, or collaboration rule changes, repeat the checks before approving a new workflow.

SECTION 01Before the project starts: define the master environment

NVivo 15 Windows and Mac collaboration should begin with governance, not file exchange. Cross-platform conversion can be possible without being suitable for repeated two-way movement. A project that travels back and forth through manually converted copies becomes difficult to audit because no one can be certain which copy contains the authoritative coding, query results, or memo changes.

At the kickoff meeting, record these decisions:

• Which platform owns the master project.
• Who is responsible for accepting changes.
• Which member performs the final queries, reports, and exports.
• Which operating system and main NVivo version each member uses.
• Which project elements each member is allowed to edit.
• Where read-only originals, working copies, and delivery exports are stored.
• Which actions require approval before execution.

If the research plan depends on the complete Windows feature set, Windows should normally host the master project. Mac users can then receive a tested working copy and perform only the coding or review tasks that passed validation. This is safer than selecting a platform based only on the computer owned by the lead student.

The same decision applies to a mixed qualitative research team spread across universities. A convenient local device is not automatically the correct system of record. Your master environment must be the platform on which the project’s required queries, relationships, reports, media handling, and exports can be reproduced.

What the platform decision should consider

Windows as the master platform may be the stronger choice when:

• The supervisor or data manager performs the final analysis on Windows.
• The project uses queries or reports that have not yet been validated on Mac.
• The team relies on external files, linked media, or complex document layouts.
• The institution’s approved NVivo collaboration or storage process is Windows-centred.
• The final thesis tables and exports must be regenerated from a Windows environment.

Mac as the master platform may be reasonable when the complete research workflow has already been tested there, every required project element is visible and usable, and the person responsible for final delivery works on Mac. Do not choose it simply because one collaborator prefers macOS.

The main risk is not that a project always becomes unreadable. The risk is that a project opens while part of the workflow is unavailable, relocated, or interpreted differently. That is why the acceptance decision must be based on evidence from your own project structure.

SECTION 02First step: create the baseline before any NVivo project conversion

The first NVivo project conversion should never be performed on the only copy. Create a read-only original, then generate a working duplicate for the conversion test. The original should remain untouched throughout the project.

Use the baseline to record:

• The source filename and file format, including .nvp or .nvpx.
• The operating system and main NVivo version used to create the file.
• The project owner and creation date.
• The number and type of source materials.
• The location of external audio, video, image, and document resources.
• The queries, reports, charts, memos, relationships, and links that matter to the study.
• The checksum or equivalent integrity record used by your institution.
• The person who approved the test copy.

Keep the inventory specific. “Media present” is not enough. Identify whether media is embedded or referenced externally, whether a document contains complex tables, and whether an image is part of an analytical memo or a source file. These details determine what must be checked after conversion.

The official cross-platform conversion instructions should sit beside your internal runbook. Follow the documented conversion process for the relevant NVivo environment, but treat it as a controlled delivery operation rather than a synchronization method.

Why repeated manual conversion creates hidden costs

A mixed-platform team usually pays for repeated conversion in four ways:

1. Version uncertainty: A member may open and save a project with a different main version, making later troubleshooting harder.
2. Change ambiguity: Two copies can contain different coding decisions without a reliable record of which change should win.
3. Attachment repair: External links may depend on paths or locations that do not exist on the receiving system.
4. Reproducibility loss: A result cited in a thesis may not regenerate from the copy used for final delivery.

There is also a permission problem. A student may have full access to the project but no authority to alter the approved storage location or move identifiable participant data to an unapproved service. Your conversion plan must therefore include account permissions, institutional storage rules, and data-processing approval, not only software steps.

SECTION 03Can A Windows NVivo project open directly on Mac?

Do not assume direct opening. Windows and Mac use different project formats, so the receiving user should follow the documented conversion path rather than opening the source file as if both applications used the same native format. A converted project may be usable, but that does not prove that every feature, link, or analysis output has transferred correctly.

For NVivo 15 Windows and Mac collaboration, answer the question at the project level:

• Can the receiving application import or convert the project through the supported process?
• Are codes, classifications, memos, and source materials visible?
• Can the Mac user open the media at the expected location?
• Do the required queries run?
• Are reports and exports available in the form your study needs?
• Can the project return to the master platform without creating an uncontrolled branch?

The official documentation should be treated as the authority for supported formats and conversion behaviour. The NVivo project creation and collaboration documentation is also relevant when your team is considering an approved collaboration mechanism instead of manual file transfer.

A project that opens successfully is only a technical pass. The acceptance pass requires the research team to confirm that the actual analytical task still produces an equivalent result.

SECTION 04Second step: run a small, representative trial conversion

Build a de-identified sample that is large enough to exercise the risky parts of your workflow, but small enough to inspect manually. Do not choose a clean project containing only text and a few codes. Include the elements that could affect delivery:

• A sample of coded documents.
• At least one memo or annotation used by the team.
• A representative query.
• A chart, report, or export required for the study.
• Audio or video with a known time position, if media is part of the research.
• A document with tables or embedded images.
• An external link that the receiving user must open.
• A small set of classifications or relationships if the study relies on them.

Perform the trial from Windows to Mac or Mac to Windows, depending on the planned delivery direction. Save screenshots, query outputs, file paths, and observations. Do not record only “works” or “fails.” Separate findings into three groups:

• Passed: The element is visible, accessible, and produces the expected result.
• Limited: The element exists but requires a different action, a supported workaround, or completion on the master platform.
• Blocked: The required action cannot be completed reliably on the receiving platform.

The distinction between “not visible in this view” and “deleted from the project” matters. Check the official feature and conversion guidance before treating an item as lost. A user-interface difference may hide an element without removing its underlying data.

SECTION 05Third step: validate coding and attachment paths

The trial must include a controlled coding exercise. Give a Windows member and a Mac member the same small set of de-identified materials and the same coding instructions. Keep the task narrow and documented.

Compare:

• Code names and hierarchy.
• Coding locations and boundaries.
• Comments or annotations.
• Memo content.
• Query results.
• Media playback and time positioning.
• External document and image access.
• Exported output and naming.
• Any warning, unavailable command, or changed display.

This is where the .nvp and .nvpx distinction becomes a research-control issue rather than a file-extension detail. If the Mac copy can display the source but cannot reproduce a query used in your analytical protocol, Mac should not receive that task until the limitation is resolved. If an external media link opens on Windows but points to a missing location on Mac, repair the controlled path or change the delivery method before formal coding begins.

Do not enlarge the project while a critical test is blocked. Restrict the Mac user to validated coding, annotation, or review tasks and send analysis-intensive work back to the master platform. This is cheaper than discovering during thesis submission that a team member’s contribution cannot be reconciled.

SECTION 06Fourth step: control formal exchange and stage merges

During formal coding, stop treating converted files as ordinary shared documents. Define a change protocol that every member can follow:

1. The master owner creates the approved exchange copy.
2. The copy receives a clear filename containing project identity, platform, version, and handoff status.
3. The recipient confirms receipt before editing.
4. The recipient works only within the agreed task boundary.
5. The recipient records changes, warnings, and blocked functions.
6. The recipient returns the file through the approved channel.
7. The master owner preserves the returned copy before accepting changes.
8. The team verifies the affected codes, sources, memos, and outputs.
9. The delivery log records the decision and the next approved copy.

Never allow two members to edit separate descendants of the same project unless your team has a documented merge method and has tested it with the exact project structure. A shared folder does not solve conflicting edits. It may also violate institutional rules if participant data is stored outside the approved environment.

If your institution supports an official collaboration feature, compare it with your account, licensing, storage, and privacy requirements before adoption. The official collaboration documentation is more useful here than informal claims that a cloud workflow will automatically remove platform differences. Collaboration controls may change the exchange process, but they do not remove the need to validate media, queries, exports, and platform-specific functions.

After a version upgrade or the addition of a new analysis feature, reopen the baseline sample and repeat the affected tests. The official NVivo 15.3 release information should be checked for confirmed changes. Do not use an unconfirmed feature alignment claim as a reason to widen Mac permissions.

SECTION 07Fifth step: complete the thesis delivery and archive acceptance

Before final submission, return to the master platform and regenerate every query, chart, table, and export cited in the thesis. Do not rely on a file created during an earlier exchange if the underlying project has changed.

Your final acceptance should confirm:

• The master project opens without an unexpected conversion prompt.
• All approved source materials are present.
• Codes and coding boundaries match the signed-off analysis.
• Memos and annotations required for interpretation are available.
• External files open from the approved location.
• Audio and video references point to the intended positions.
• The queries used in the thesis run on the master platform.
• Exported tables and reports match the final written analysis.
• The project version and platform are recorded.
• Recovery instructions can be followed by someone other than the project owner.

NVivo’s official export guidance should be used when defining the export set. Preserve the master project, the controlled exchange copy, final exports, the version note, the conversion record, and recovery instructions as separate archive items.

If your lab has no Mac, perform one final receiving-side acceptance using a separately controlled remote Mac before archiving. That test should use a de-identified project and confirm only the tasks that a Mac collaborator is expected to perform. A remote environment is not a substitute for institutional approval, but it can expose a delivery problem before the final deadline.

SECTION 08The delivery decision: master platform, exchange copy, and fallback

Use the checklist below at each project milestone. Stop the handoff when a required item remains unchecked.

• [ ] The team has named one master project platform and one responsible owner.
• [ ] Each member’s operating system and main NVivo version are recorded.
• [ ] The original project is read-only and stored in the approved location.
• [ ] The file format is recorded as .nvp or .nvpx.
• [ ] External media, documents, images, and links are inventoried.
• [ ] A de-identified trial project includes codes, memos, queries, media, and links.
• [ ] The supported conversion process has been followed on a working copy.
• [ ] The receiving platform’s required features are visible and usable.
• [ ] Sample coding has been compared across platforms.
• [ ] Attachment paths and media positions have been checked.
• [ ] Blocked functions have been assigned back to the master platform.
• [ ] Exchange filenames, permissions, backups, and handoff records are defined.
• [ ] A new version or feature has been tested against the baseline before approval.
• [ ] Final queries, reports, and exports have been regenerated on the master platform.
• [ ] The archive contains recovery steps that another team member can follow.

The following comparison helps you choose a controlled workflow without pretending that every project has the same requirements.

SECTION 09What to do when the lab has no Mac

Do not purchase a Mac solely to answer an untested compatibility question. First, prepare a de-identified sample, define the Mac user’s expected tasks, and use a separately controlled remote Mac to check opening, attachment access, coding, query review, and export acceptance.

For a temporary research environment, review MACNOX’s remote Mac access options only after your data-handling requirements are clear. You receive the most useful evidence when the remote machine has independent access, the sample project contains the real risk areas, and the test is tied to a thesis or project delivery milestone.

A remote Mac is not the best long-term answer for every team. A stable, intensive workflow may justify buying and managing an approved local device. A project that requires physical laboratory instruments, local drivers, or restricted institutional networks may not fit a hosted machine. The remote option is most defensible when you need short-term validation, one Mac-side collaborator, or a temporary bridge before the institution decides on permanent equipment.

For planned rental use, compare the available MACNOX pricing information with the period you actually need. Do not select a plan before checking account permissions, approved data locations, and whether your NVivo license permits the intended remote deployment.

The operational conclusion is straightforward: NVivo 15 is not a good candidate for repeated manual conversion between Windows and Mac. Choose one master platform, align the main version, test a representative project before formal coding, and narrow the receiving user’s permissions when a required function is not validated. If your lab has no Mac, a temporary independent remote Mac can expose delivery failures before they affect your thesis archive; after that evidence, you can decide whether a single-platform workflow or a permanent dual-platform setup is justified.

SECTION 10Further Reading

• Research Project Acceptance Testing on a Remote Mac
• Access Control for Shared Mac Research Workstations
• Apple Silicon Migration Planning for Research Software