Primavera P6 vs Unifier vs Aconex vs Textura

The forecast in the monthly report doesn’t match the forecast in the cost system. Someone asks which one is right, and the honest answer is that nobody knows, because there are three places holding a number and nobody ever wrote down which one wins.

That conversation is usually the first sign that an organisation bought two Oracle products without deciding what each one was for. It is a common outcome, and it is not because the products are bad. It’s because they are sold as a suite, they overlap on purpose, and the sales conversation is about capability rather than authority.

This post is a working comparison of the four Oracle Construction and Engineering products people most often confuse: Primavera P6 vs Unifier vs Aconex, plus Textura. One profile each, what it genuinely owns, where it wins, where it doesn’t, and then the part nobody covers: how to decide which system holds the authoritative number when three of them offer a cost module.

The question that actually sorts them

Feature lists will not separate these products. All four manage documents. Three of them track cost. Two of them hold a schedule. If you compare capability columns you will conclude that you need all four, which is exactly the conclusion the suite is designed to produce.

The question that does separate them is: whose record is this, and who else needs to write to it?

Two of these products are single-organisation systems. You run them, you own the data, and outside parties get in only if you give them a seat and they accept your governance. One of them is deliberately multi-organisation, where every company on the project holds its own workspace and decides what it shares. And one is a transactional network that touches money leaving your bank account, which makes it a finance system wearing a construction badge.

Get that axis right and the rest of the decision mostly falls out.

Primavera P6: the schedule, and only the schedule

P6 is a critical path method scheduling engine with resource and cost loading on top. It exists to answer questions about time: what drives the finish date, what happens if this activity slips, what does the resource histogram look like if we accelerate.

Two things confuse people here. First, P6 comes in two shapes. P6 Professional is the desktop client that planners actually live in. P6 EPPM is the enterprise web layer with the shared database, portfolio views and web services. Most organisations run both against the same database, and most planners will fight you to keep the desktop client.

Second, Oracle Primavera Cloud is a separate product, not P6 in a browser. Oracle says so on its own product page, which is unusually direct for vendor copy. Primavera Cloud shares a lineage with P6 and is positioned as the cloud destination, but the data model is not identical and things planners rely on in P6 do not all have equivalents. If someone tells you a move to Primavera Cloud is a hosting change, they have not tried it.

Where P6 wins

Contractual programme scheduling, where the schedule is a deliverable and gets audited
Forensic delay work, because the XER and PMXML formats are what every expert and every third-party analysis tool expects
Resource-loaded planning across a portfolio with a shared resource pool
Anywhere the client’s contract names it, which is more places than you would expect

Where P6 doesn’t

Cost control. P6 has cost fields and they are useful for cash flow shape, but a resource-loaded schedule is not a commitment ledger. It has no concept of a purchase order lifecycle, a variation approval or a payment certificate
Correspondence and document control. There is nothing here for transmittals, RFIs or drawing registers
Collaboration across companies. Subcontractors do not get P6 logins, and you would not want them writing to your programme if they did

Primavera Unifier: a business process engine that happens to know about projects

Unifier is the one people describe worst, usually as “the cost one”. That undersells it and also sets bad expectations.

Unifier is a configurable workflow platform for capital programmes. You define business processes: a change order, a funding request, an invoice, a payment application, a site instruction. Each one has a form, a workflow with approval steps and routing rules, and a defined effect on the cost sheet. Oracle ships preconfigured processes and a no-code designer called uDesigner for changing them or building your own. Alongside the business processes sit the managers, including the Cost Manager, Schedule Manager and Document Manager.

It’s sold as base products, principally Project Controls and Facilities and Asset Management, which matters because Unifier’s remit runs past handover into operating the asset.

The honest trade-off with Unifier is this: its configurability is the reason to buy it and the reason implementations run long. A platform that can model any approval workflow will not tell you what your approval workflow should be. If your organisation has not written its cost control process down, Unifier will faithfully automate the argument you are having instead of the process you wanted.

Where Unifier wins

Owner-side capital programme control, where budget, funding, commitments, forecast and actuals need to roll up across many projects
Anywhere approvals need an audit trail with defined routing, delegation and thresholds
Public sector and utility programmes with fund tracking, where money has strings attached and the strings must be reportable
Organisations that want one governed process applied to every project rather than per-project improvisation

Where Unifier doesn’t

Supply chain collaboration. It’s your instance, your governance, your seats. External parties can be given access, but they are guests in your system and they behave like it
Drawing and model control at scale. The Document Manager is real, but it is not a common data environment and it is not built for design coordination
Fast starts. Configuration is a project in its own right, and treating it as an install is the most common way to burn a first year

Aconex: the project record, owned by nobody in particular

Aconex is a common data environment for correspondence, documents, workflows and models across every organisation on a project. Document control, transmittals, RFIs, submittals, drawing registers, model coordination, field inspections.

Its defining property is not a feature. It is the data ownership model. Every organisation on the project gets its own workspace and controls what it shares and when. That neutrality is the entire commercial argument, and it is the thing you cannot replicate by inviting subcontractors into your instance of something else.

This matters more than it sounds. A designer who believes the main contractor can read their internal drafts will keep their real work somewhere else, and your “single source of truth” quietly becomes a partial one. The reason Aconex accumulates a complete project record is that nobody is afraid of it. Oracle’s own materials lean on that neutrality hard, and in this case the marketing claim and the engineering consequence are the same thing.

On the model side, Aconex Model Coordination is design-neutral and built on open BIM standards including IFC and BCF, so it sits alongside the authoring tools rather than replacing them.

Where Aconex wins

Multi-party projects where the correspondence record will be read by lawyers later
Design-build and joint venture delivery, where no single party should hold everyone’s data
Document and model volume, which Oracle’s datasheets describe as unbounded on data and participants
Handover, because the audit trail and the linked document set are the deliverable

Where Aconex doesn’t

Portfolio-level capital planning. Aconex is organised around projects, not around a programme of investment decisions
Asset lifecycle after handover. The record ends where the project ends
Deep enterprise cost governance. Connected Cost exists and is genuinely useful for project cost, but if your organisation needs funding, capital planning and multi-year rollup, that is Unifier’s shape

Textura: money leaving the building

Textura came into Oracle by acquisition and still feels different from the rest of the suite, because it is solving a different class of problem.

Textura Payment Management runs the construction payment cycle: initiating a draw, subcontractor pay applications, markups and approvals, owner billing, collecting lien waivers and compliance documents, enforcing compliance holds, payment authorisation and disbursement. It’s a network product. Your subcontractors transact in it, and the value comes from them being there.

The compliance side is the part that decides whether it’s worth buying. If your risk is a subcontractor’s insurance lapsing quietly and nobody noticing until a claim, an automated payment hold tied to a missing document is a control you cannot easily build with a spreadsheet and good intentions.

Where Textura wins

General contractors with a wide subcontractor base and a monthly draw cycle that eats accounts payable alive
Jurisdictions with real lien exposure, where waiver collection is a legal control rather than paperwork
Compliance enforcement at the point of payment, which is the only moment anyone reliably pays attention
Audit trails on who approved what, signed what and released what

Where Textura doesn’t

It is not a cost control system. It handles the payment leg, not the budget, forecast or commitment ledger
It does not replace your ERP. It integrates with it, and that integration is part of the implementation cost
Adoption is a supply chain problem, not a software problem. If your subcontractors will not onboard, you own a slower process than the one you replaced

The overlap trap, and why the cost module is where it bites

Here’s the failure mode that is invisible at procurement and expensive eighteen months later.

Three of these products can hold cost. P6 has cost-loaded activities. Unifier has a full Cost Manager. Aconex has Connected Cost. Nobody sets out to run three cost systems, but it happens gradually: the schedule gets cost-loaded because the client asked for an S-curve, the finance team runs the commitment ledger in Unifier, and the project team starts logging variations in Aconex because that’s where the correspondence already is.

Now you have three forecasts. They disagree. Not because anyone is wrong, but because they are answering different questions with different cut-off dates and different accrual rules. And the reconciliation lands in a spreadsheet maintained by one person, which is the outcome every one of these products was bought to prevent.

The fix is a decision, not a tool. Before anything is configured, write down one sentence per data class: which system is authoritative, and what the others are allowed to hold.

Schedule dates and logic: P6 is authoritative. Everything else receives dates, nothing else edits them
Budget, commitments and forecast: pick one. If you own Unifier, it is Unifier. If you don’t, Connected Cost is a reasonable home, but say so out loud
Correspondence and controlled documents: Aconex if it’s on the project, and if it is, do not run a parallel drawing register anywhere else
Subcontractor payment and compliance status: Textura, with the resulting actuals flowing to whichever system owns cost
Everything the authoritative system does not own: read-only, refreshed by integration, and clearly labelled in reports as a copy

That list takes an afternoon and saves a year. It’s also the single most common thing missing from Oracle Primavera implementations I get asked to look at.

Integration is the real cost, and it has a shape

Once you own two of these, you own an integration. Budget for it as a workstream, not a checkbox.

Oracle offers more than one path. Primavera Gateway is the established broker for P6 and Unifier, with built-in providers per application and a canonical intermediate format so mappings survive version changes. In the P6 to Unifier direction, Gateway maps the P6 Project ID to Unifier’s Project Number, and what flows depends on how the schedule is built: a duration-based schedule sends durations, a resource-loaded one sends durations and units. Oracle also has a lighter integration platform for exchanging data between Unifier, P6, Aconex and Primavera Cloud, so check which one your version and deployment model actually supports before designing anything.

Aconex Connected Cost takes a different route, talking to P6 over its web services API. Two constraints from that integration are worth knowing before you draw an architecture diagram:

You can configure both a P6 and a Primavera Cloud integration for the organisation, but an individual project can only link to one of them at a time
Self-hosted or third-party-hosted P6 servers have to be approved by Oracle and reachable over the internet before the integration can be established. Oracle-hosted P6 skips that approval step

That second one has teeth if you are running P6 EPPM on your own infrastructure. “Internet accessible” and “exposed” are not the same thing, and the gap between them is where your security review lives. If you’re standing up middleware or a reverse proxy in front of an on-premise P6 or Unifier deployment, that box needs to be treated as production: a dedicated host from a provider like Contabo or InterServer rather than a corner of an existing server, TLS terminated properly, access restricted to known networks, and remote administrative access over a business VPN such as NordLayer or Surfshark rather than a port forward someone opened for a consultant and forgot about.

Back up the database host properly too, and test a restore. On-premise P6 and Unifier estates are frequently the last thing anyone thinks about until they need it, and imaging tools from vendors like O&O Software earn their keep on exactly this kind of long-lived, rarely-touched server.

How I’d decide

Work through this in order and stop at the first answer that fits. Buying more than you need is far more common than buying too little.

Name the pain in one sentence. “We cannot defend our programme in a delay claim” points at P6. “We cannot tell the board what the capital programme will cost” points at Unifier. “We cannot find the approved revision” points at Aconex. “Subcontractor payments take six weeks and compliance is a filing cabinet” points at Textura
Count the organisations that must write to the system. One, and you are choosing between P6 and Unifier. Many, and you are choosing between Aconex and Textura
Ask whether the problem outlives the project. Assets, maintenance and multi-year capital planning are Unifier’s territory. Anything that ends at handover is not
Check what the contract already mandates. Plenty of clients name a scheduling tool or a project CDE in the contract documents. That decision is made, so spend your effort elsewhere
Ask the reseller how each product meters. Per named user, per project, per transaction or per value processed changes the architecture, not just the invoice. A per-user product pushes you towards fewer, more senior users, and that changes who does data entry
Only then decide on a second product, and write the system-of-record sentence for every data class the two of them share before signing anything

Arguments that don’t survive contact

“Unifier can do document control, so we don’t need Aconex.” Technically true, practically false on multi-party projects. The obstacle is not features, it is that other companies will not put their real correspondence in your instance
“Aconex has cost, so we don’t need Unifier.” Fine for project-level cost. It falls down when you need portfolio funding, capital planning and asset lifecycle
“Primavera Cloud is just P6 in the browser.” Oracle itself states that Primavera Cloud is not P6. Treat any migration as a data model exercise with a gap analysis, not a lift and shift
“We’ll integrate it later.” Later means after users have created data under two incompatible breakdown structures. Agree the project and cost breakdown codes on day one, even if the integration itself waits
“The suite integrates out of the box.” Connectors exist and they are good. Mapping your codes, your workflow states and your calendars is still work, and it is work that needs someone who understands both sides

Practices worth adopting early

Standardise the project ID before anything else. Gateway maps P6’s Project ID to Unifier’s Project Number, and a free-text naming convention will hurt on the day you connect them
Keep the schedule in one place and let it flow outward. Bidirectional date editing across two systems is a support ticket generator
Pilot Unifier configuration on one real process end to end before configuring twenty. uDesigner makes it easy to build the wrong thing quickly
Onboard the supply chain before go-live on Aconex or Textura. Network products fail on adoption, not on uptime
Export your own data on a schedule. XER and PMXML for schedules, and regular extracts from the cloud products, so you are not negotiating from zero at renewal
Write the system-of-record statement into the implementation charter, where people will actually see it

FAQ

What is the difference between Primavera P6 and Unifier?

P6 is a critical path scheduling tool that answers questions about time and resources. Unifier is a configurable business process and cost platform that answers questions about money, approvals and governance across a capital programme. They overlap slightly because P6 can hold cost data and Unifier has a Schedule Manager, but neither is a substitute for the other.

Do I need Aconex if I already have Unifier?

If the project involves several independent organisations exchanging drawings and correspondence, usually yes. Unifier’s Document Manager works well for your own records, but external parties are guests in your instance. Aconex gives every organisation its own workspace and control over what it shares, which is what makes the project record complete rather than partial.

Is Oracle Primavera Cloud replacing P6?

Oracle positions Primavera Cloud as the cloud platform and publishes migration guidance from P6, while continuing to sell and support P6 EPPM. Oracle also states plainly that Primavera Cloud is not P6. Plan on the two coexisting for now, and treat any migration as a data model exercise with a proper gap analysis rather than a hosting change.

Can Textura replace our accounting system?

No. Textura handles the construction payment cycle: pay applications, approvals, lien waivers, compliance holds and disbursement. It integrates with ERP systems rather than replacing them, and that integration is a real line item in the implementation.

Which product should a general contractor start with?

It depends on which pain is loudest. If schedules are being disputed, P6. If the project record is scattered across email, Aconex. If the monthly draw cycle and subcontractor compliance are consuming the finance team, Textura. Contractors reach for Unifier less often than owners do, because Unifier’s strengths are programme-level funding and governance.

How hard is it to integrate P6 with Unifier?

The mechanism is well trodden through Primavera Gateway, which ships providers for both. The hard part is not the connector, it’s agreement: matching project identifiers, deciding which system owns dates, and reconciling breakdown structures that were designed independently. Expect the mapping work to take longer than the technical setup.

What data should I be exporting for portability?

For schedules, take regular XER and PMXML exports, since those formats are what independent analysis tools and delay experts read. For the cloud products, set up scheduled extracts of documents, transaction records and audit trails. The point is not distrust of the vendor, it’s that a project record you cannot read without an active subscription is a liability during a dispute.

The one thing worth remembering

The Primavera P6 vs Unifier vs Aconex comparison, with Textura alongside them, is not really a features question. Each of these products is good at the thing it was built for, and Oracle is not trying to trick anyone by giving three of them a cost module.

The damage comes from owning two of them and never deciding which one is authoritative. Sort the products by whose record they hold and how many organisations write to them, pick the smallest set that covers your loudest pain, and write down the system of record for every data class before a single workflow gets configured.

Do that and the monthly report matches the cost system. Skip it and you’ll meet the spreadsheet.

Need help untangling this?

Most of the work in this area is not clicking through screens, it’s the plumbing and the decisions around it. That part I can help with:

Writing the system-of-record map for your data classes before you commit to a second Oracle product, so cost and dates have one owner each
Designing and building integrations between P6, Unifier, Aconex, Textura and your ERP, including the field mapping and error handling nobody scopes
Hardening on-premise P6 EPPM or Unifier deployments that need to be reachable for a cloud integration, with proper TLS, network restrictions and audited access
Automating schedule and cost data extraction into a warehouse or BI layer, so reporting stops depending on someone manually exporting on a Friday
Building repeatable backup, restore-testing and disaster recovery for self-hosted Primavera estates
Second-opinion reviews on an implementation or integration design that already exists and is not behaving

If you’re stuck on something concrete, send it over: an integration mapping spec, a Gateway error, a network diagram for an on-premise P6 that needs to talk to a cloud service. Easier to give you something useful when I can see the actual thing.

Work with me on Upwork