A VP of Sales Operations at a mid-sized manufacturer signs a Salesforce contract for 120 users. The licence line in the budget is clear to the dollar. The implementation line says “partner, about six months”. Nine months later the system is live, but the ERP integration fails every few days, a third of the sales team still keeps pipelines in spreadsheets, and the company pays for licences that nobody logs into. The licences were the easy part of the budget. The implementation was the part that determined whether the licences were worth anything.
This article is for the person who has to plan that second part. We break a Salesforce implementation into phases, roles and hours, price a 120-user rollout step by step, show what changed in Salesforce pricing in 2025 and 2026 — including the Core, Advanced and Max editions introduced on 3 September 2026 — and compare three ways to deliver the work: a Salesforce SI partner, an in-house team and staff augmentation.
A note on who is writing. ARDURA Consulting is not a Salesforce partner and does not sell Salesforce licences. We provide developers, QA engineers and integration specialists who work inside client and partner teams, and we run software asset management for licence portfolios, Salesforce included. That position lets us describe the options without a stake in any single one of them.
What does a Salesforce implementation actually include in 2026?
A Salesforce implementation is not the act of switching the product on. The platform is available the day the contract is signed. The implementation is everything needed to make it support your processes: data model and configuration, automation, integrations with other systems, data migration, security and access, testing, training and the first weeks of live operation.
In practice, the scope splits into four layers, and each has a different cost profile:
- Configuration. Objects, fields, page layouts, record types, sharing rules, reports and dashboards. Done in the browser by an administrator or consultant, without code. Fast and cheap to change — as long as it stays configuration.
- Automation and custom logic. Flows, validation rules, approval processes and, where configuration is not enough, Apex code and Lightning Web Components. This layer grows fastest when requirements are unclear.
- Integrations and data. Connections to ERP, marketing automation, e-commerce, telephony, data warehouses; migration of historical data from the previous CRM and spreadsheets. Usually the riskiest part of the project.
- People and operations. Training, change management, support after go-live, the release process and ongoing administration.
The product names themselves changed recently. At Dreamforce 2025, Salesforce rebranded Sales Cloud as Agentforce Sales and Service Cloud as Agentforce Service under an “Agentforce 360” umbrella. By September 2026 the Sales Cloud name was back on Salesforce’s own price list. For implementation purposes nothing changed: objects, APIs and existing configuration work the same way under either name. We use “Sales Cloud” and “Service Cloud” in this article because that is what most teams still search for.
How much does Salesforce cost in 2026 after the switch to Core, Advanced and Max?
Salesforce changed its price list twice in fourteen months. On 1 August 2025, list prices for Enterprise and Unlimited editions of Sales Cloud, Service Cloud, Field Service and selected Industries clouds rose by an average of 6%, according to Salesforce’s own announcement. Starter, Pro and Salesforce Foundations were not affected. At the same time, Agentforce add-ons (from USD 125 per user per month) and Agentforce 1 editions replaced the earlier Einstein add-ons.
On 3 September 2026, Salesforce introduced three new editions for Agentforce Sales, Agentforce Service and Agentforce Industries — Core, Advanced and Max — which bundle Agentforce, Slack, embedded analytics, data security features and a Premier Success Plan. For Sales Cloud, the list prices on salesforce.com (checked in September 2026) are:
| Edition | List price (per user / month) | What it replaces | Flex Credits included |
|---|---|---|---|
| Starter Suite | USD 25 (monthly or annual billing) | — | — |
| Pro Suite | USD 100 (annual billing) | — | — |
| Core | USD 195 (annual billing) | Enterprise (USD 175) | 500,000 per org per year |
| Advanced | USD 395 (annual billing) | Unlimited (USD 350) | 1,000,000 |
| Max | USD 550 (annual billing) | Agentforce 1 (USD 550) | 2,750,000 |
According to Salesforce Ben’s coverage of the announcement, existing customers keep their legacy edition pricing, and Agentforce 1 customers can move to Max at no extra cost. Salesforce claims Core delivers 70% more value than the legacy Enterprise edition. Whether that value is real depends on whether you would otherwise buy Slack, analytics and a Premier Success Plan separately.
Three practical conclusions for budgeting:
- For a new customer, the realistic entry point for a mid-sized implementation is Core, not Pro Suite. Pro Suite is designed for small teams; Core includes the API access and advanced pipeline features most integrated implementations need.
- List price is a starting point. Enterprise agreements are negotiated, and multi-year commitments, user volumes and bundles move the final price. Budget from the list price and treat the discount as upside.
- Price increases are part of the model. The 2025 increase followed a 9% rise in 2023. A three-year budget should assume that renewal prices will not stay flat.
How much does a Salesforce implementation cost?
Implementation is priced in hours of a mixed team, so the only honest way to estimate it is to build the team. Here is a worked example with explicit assumptions.
The scenario. A company with 120 users: 60 in sales, 60 in customer service. Scope: Sales Cloud and Service Cloud, a lead-to-order process, case management, a two-way integration with the ERP (accounts, products, orders, invoices), migration of five years of data from the previous CRM, standard reports and dashboards. Duration: six months to go-live plus six weeks of hypercare. Rates come from our body leasing rate benchmark for 2026, in which Salesforce specialists cost PLN 200–350 per hour. We assume 160 hours per full-time month and convert at 3.70 PLN per USD.
| Role | FTE | Rate (PLN/h) | Months | Hours | Cost (PLN) |
|---|---|---|---|---|---|
| Salesforce solution architect | 0.5 | 330 | 6 | 480 | 158,400 |
| Salesforce developers (Apex, LWC) | 2.0 | 260 | 5 | 1,600 | 416,000 |
| Salesforce administrator / consultant | 1.0 | 220 | 6 | 960 | 211,200 |
| Business analyst | 1.0 | 190 | 5 | 800 | 152,000 |
| QA engineer | 1.0 | 150 | 4 | 640 | 96,000 |
| Project manager | 0.5 | 220 | 6 | 480 | 105,600 |
| Data migration specialist | 0.5 | 230 | 3 | 240 | 55,200 |
| Hypercare (admin + 0.5 developer) | 1.5 | — | 1.5 | 360 | 84,000 |
| Total | ≈230 average | 5,560 | 1,278,400 |
The implementation costs about PLN 1.28 million (about USD 345,500). Licences for 120 Core users cost USD 280,800 a year (about PLN 1.04 million). Had the same company signed before September 2026 on Enterprise at USD 175, the licence line would have been USD 28,800 a year lower.
Over three years, with one full-time administrator after go-live (PLN 422,400 a year at the same rates), the total cost of ownership reaches about PLN 5.66 million (USD 1.53 million): 55% licences, 23% implementation and 22% ongoing administration. Two conclusions follow. First, implementation is not the biggest cost over time — licences are, which is why licence management matters as much as delivery. Second, cutting implementation scope to save money and then paying three years of licences for a system people do not use is the most expensive option of all.
Your numbers will differ. A pure Sales Cloud rollout without integrations can take a third of these hours; a multi-cloud programme with CPQ, Experience Cloud and several ERPs can take five times as many. The structure of the calculation stays the same.
What are the phases of a Salesforce implementation?
Most implementations follow the same sequence, whatever the methodology on the cover of the proposal:
- Discovery. Current processes, target processes, data sources, integrations, reporting needs, security requirements. The output is a backlog and an architecture outline. Our article on BPMN 2.0 in practice shows how to describe processes precisely enough for a vendor to price them.
- Solution design. Data model, sharing model, the decision on what is configuration and what is code, integration patterns, environment strategy, data migration approach.
- Build. Configuration, automation and development, delivered in sprints with regular demos to business users.
- Data migration. Mapping, cleansing, deduplication, test loads and at least one full rehearsal of the cutover.
- Integrations. Built and tested against realistic data volumes, with error handling agreed in advance.
- Testing. Functional, integration, performance where relevant, and user acceptance testing with the people who will use the system.
- Training and change management. Role-based training, champions in each team, updated procedures.
- Go-live. Final data load, integration switch-over, access for all users.
- Hypercare. Four to eight weeks of heightened support, rapid fixes and adjustments.
The phases overlap in agile delivery, but none of them can be skipped. When a project runs late, the phases that get squeezed are almost always migration rehearsals, testing and training — the three that decide whether go-live succeeds.
Typical durations: a single-cloud rollout for a small team with standard processes can go live in 6–12 weeks. A mid-sized implementation like our example takes 4–8 months including hypercare. Multi-cloud programmes across several business units run for a year or more and are delivered in releases rather than one go-live.
When should you configure and when should you write Apex?
Salesforce is a platform on which almost anything can be built. The question is not “can we”, but “what will it cost to maintain”. Every line of Apex needs tests, reviews and attention at each of the three major releases Salesforce ships every year. Every Flow needs documentation and an owner.
The working rule we see in successful implementations:
- Standard functionality first. If a standard object and process do 80% of the job, adapt the process before customising the platform.
- Declarative configuration next. Fields, validation rules, record-triggered and screen Flows, approval processes. Administrators can maintain them.
- Apex and Lightning Web Components when needed. Complex calculations, high data volumes, sophisticated integrations, logic that must be unit-tested thoroughly, or user interfaces that standard components cannot deliver.
Two platform facts shape this decision. First, Workflow Rules and Process Builder reached end of support on 31 December 2025. Existing automations keep running, but Salesforce no longer fixes bugs or provides support for them, and all new investment goes into Flow. An implementation in 2026 should not create any new Workflow Rules or Process Builder processes, and a migration to a new org is a good moment to convert the old ones. Second, Apex requires at least 75% test coverage to deploy to production, and every trigger must have some coverage. That threshold is a gate, not a quality target — Salesforce itself recommends aiming higher.
The most common source of long-term cost is not Apex itself but uncontrolled mixing: a Flow, a trigger and a validation rule on the same object, each written by a different person, firing in an order nobody documented. Agree on an automation strategy per object during solution design, and enforce it in code review.
How do you migrate data into Salesforce without breaking reporting?
Data migration fails for a predictable reason: it is treated as a technical copy rather than a business decision about which data is worth keeping. The questions to settle before anyone writes a mapping:
- What history do we really need? Five years of closed opportunities may be valuable for forecasting; ten years of inactive leads usually are not.
- Who owns each data set? Someone in the business must decide how duplicates are merged and which source wins in a conflict.
- What is the target data model? Record types, picklist values and account hierarchies must be fixed before migration, not adjusted after it.
Salesforce provides two standard tools with very different reach. The Data Import Wizard handles up to 50,000 records at a time and suits simple imports of accounts, contacts and leads. Data Loader handles up to five million records per operation and is the usual choice for full migrations, often alongside ETL tools or middleware when transformations are complex.
A migration plan that works includes at least two full test loads into a sandbox with production-like data, reconciliation reports comparing record counts and key totals between the old system and Salesforce, and a rehearsed cutover with a timed runbook. Our data migration glossary entry covers the general principles.
The most expensive migration mistake is loading dirty data “to clean up later”. Later rarely comes, and reports built on duplicated accounts undermine trust in the system from the first week — which is exactly when users decide whether to adopt it.
How do you plan integrations with ERP, marketing and support tools?
In most implementations, Salesforce becomes valuable only when it is connected to the systems around it: prices and stock from the ERP, orders and invoices back to finance, leads from marketing automation, cases from the contact centre. Integrations are also where most go-live incidents originate.
Plan each integration as a small product with its own design:
- Direction and ownership. Which system is the master for each object — accounts, products, prices, orders? Two-way synchronisation without a clear master produces conflicts.
- Pattern. Real-time API calls, event-driven messaging or scheduled batches. Real-time is not always better; nightly batches are simpler and cheaper when the business does not need minute-level freshness.
- Middleware or point-to-point. With two integrations, point-to-point may be enough. With five or more, an integration platform — MuleSoft, which Salesforce owns, or another iPaaS — pays for itself in monitoring and reuse.
- Limits. Salesforce enforces API and governor limits per org and per transaction. High-volume integrations must be designed around them, not discovered in production.
- Error handling. What happens when the ERP is unavailable? Retries, queues, alerts and a person responsible for resolving failed messages.
For a broader view of integration architecture, see our article on how IT systems integration connects technological islands. Integration testing deserves its own place in the test plan, with realistic volumes and failure scenarios, not only the happy path.
What roles does a Salesforce implementation team need?
Whoever delivers the implementation, the same roles have to be covered. In small projects one person may combine two roles; in large ones each role becomes a team.
| Role | Responsibility | Can one person combine it with |
|---|---|---|
| Product owner (client side) | Priorities, decisions, acceptance; represents the business | Nobody external — must be on the client side |
| Solution architect | Data model, sharing, integration patterns, configuration vs code decisions | Lead developer in small projects |
| Salesforce administrator / consultant | Configuration, Flows, reports, user management | Business analyst in small projects |
| Salesforce developer | Apex, Lightning Web Components, integrations, deployment | Integration engineer |
| Business analyst | Processes, requirements, user stories, UAT preparation | Administrator |
| QA engineer | Test strategy, functional and regression testing, test automation | — keep it separate from development |
| Data migration specialist | Mapping, cleansing, loads, reconciliation | Developer with ETL experience |
| Project manager / delivery lead | Plan, risks, budget, coordination | Architect in very small projects |
| Change and training lead | Communication, training, adoption | Business analyst |
Two roles are most often missing. The product owner on the client side, because companies assume the partner will “know what we need”. And the QA engineer, because configuration “does not need testing”. Both assumptions turn into defects found by users after go-live.
Partner SI, in-house team or staff augmentation: which delivery model fits?
There are three basic ways to staff the roles above, and many companies combine them.
| Criterion | Salesforce SI partner | In-house team | Staff augmentation |
|---|---|---|---|
| Accountability for delivery | Partner, under a contract | Your company | Your company; provider accountable for people |
| Speed to start | Fast, established team | Slow — hiring takes months | Fast — specialists in 1–4 weeks |
| Cost per hour | Highest (margin, methodology, overhead) | Lowest after hiring | Between the two |
| Knowledge retention | Leaves with the partner unless handed over | Stays | Stays in your documentation and processes |
| Best for | Large multi-cloud programmes, fixed scope, one accountable party | Long-term platform ownership, continuous development | Filling specific gaps, scaling capacity, QA and integrations |
| Main risk | Dependence, change requests | Time to hire, key-person risk | Needs an internal owner and architecture lead |
A certified SI partner makes most sense when the programme is large, scope is reasonably stable and you want a single party contractually accountable for the outcome. As we wrote about fixed-price contracts and who really pays for risk transfer, that accountability has a price, and change requests are where it shows.
An in-house team is the right long-term target for companies whose sales and service processes are a competitive differentiator and change constantly. It is rarely the right way to start, because hiring a full Salesforce team takes months.
Staff augmentation works well when you already have — or can appoint — a product owner and an architecture lead, and need capacity or specific skills: Apex developers, integration engineers, QA. This is where ARDURA works: our specialists join the client’s team or the SI partner the client has chosen, work in their backlog and tools, and leave knowledge in the client’s documentation. ARDURA is not a Salesforce partner, holds no Salesforce partner certification and does not lead Salesforce implementations as a partner — we add developers, QA and integration capacity alongside whoever does.
How should you test a Salesforce implementation?
Salesforce implementations are often under-tested for a simple reason: configuration looks too simple to break. In practice, an innocent change to a validation rule or Flow can stop an integration, block a sales process or expose data to the wrong users.
A test strategy should start with environments. Salesforce offers four sandbox types:
| Sandbox | Data | Storage | Refresh interval | Typical use |
|---|---|---|---|---|
| Developer | Metadata only | 200 MB | Daily | Individual development |
| Developer Pro | Metadata only | 1 GB | Daily | Development and QA with seeded data |
| Partial Copy | Metadata plus a sample of production data | 5 GB | Every 5 days | Integration testing, UAT |
| Full | Full copy of production | Same as production | Every 29 days | Performance tests, migration rehearsals, staging |
The minimum test scope covers functional tests of each user story, integration tests with realistic volumes, security and sharing tests (can a sales rep see another region’s accounts?), data migration reconciliation and user acceptance testing on a Partial Copy or Full sandbox.
After go-live, regression testing becomes permanent. Salesforce ships three major releases a year, and each one can change the behaviour of standard components your customisations depend on. Teams that automate regression tests for key processes — lead conversion, quote-to-order, case escalation — catch release issues in sandboxes during the preview window instead of in production. Our QA and testing services are often brought in exactly for this: building a regression suite that makes every release a routine event.
How do Agentforce and Flex Credits change the budget?
AI in Salesforce is no longer an optional add-on on a separate line; since September 2026 it is bundled into the Core, Advanced and Max editions with a Flex Credit allowance. That changes budgeting in two ways.
The consumption model. Salesforce introduced Flex Credits in May 2025 as a consumption-based model for Agentforce. According to salesforce.com, Flex Credits cost USD 500 per 100,000 credits. A standard agent action consumes 20 credits, or about USD 0.10. Alternatives include USD 2 per conversation for customer-facing agents and flat-fee access at USD 125 per user per month for unmetered employee use.
The allowance is smaller than it looks. Core includes 500,000 Flex Credits per org per year — about 25,000 standard actions. In our example, that is about 17 actions per user per month across 120 users. If 60 service agents each use 15 agent actions per working day across 251 working days, that is 225,900 actions, or about 4.5 million credits a year. The overage — about 4 million credits — costs roughly USD 20,000 a year at list price.
Three recommendations follow:
- Model AI usage per process, not per user. Which actions will agents perform, how often, for whom?
- Pilot before committing. Measure real consumption in a sandbox or a limited rollout before signing a volume.
- Monitor consumption like cloud spend. Flex Credits behave like cloud resources: without monitoring, the bill arrives before anyone notices the growth. Our article on FinOps for software licences describes how to govern consumption-based licensing.
Why do Salesforce implementations fail, and how do you prevent it?
Salesforce implementations rarely fail because of the platform. They fail for organisational reasons that repeat from project to project:
- No business owner. IT runs the project, sales and service “will use it when it’s ready”. Adoption stays low because nobody in the business owns the outcome.
- Replicating the old system. Every legacy report, screen and workaround recreated in Salesforce, often in custom code. The company pays for a new platform and gets the old one back.
- Over-customisation. Apex where Flow would do, custom objects where standard ones fit. Each customisation adds maintenance cost at every release.
- Dirty data. Duplicates and incomplete records migrated as-is. Reports are wrong from week one, and trust never recovers.
- Integrations as an afterthought. Designed late, tested with ten records, failing at production volumes.
- Too little testing and training. Both squeezed when the timeline slips.
- Unmanaged licences. Users who left or never adopted the system still have licences. At USD 195 per user per month, 15% unused seats in our example cost USD 42,120 a year.
The last point is where implementation meets change management and licence management. Track logins and feature usage from the first month. Low usage is an early signal of an adoption problem, and it is also money that can be recovered — our guide to license harvesting in 2026 explains how to reclaim unused SaaS seats before renewal.
How do you check that a Salesforce implementation is ready — and stays under control after go-live?
The checklist below summarises what to have in place at each stage. Use it before signing with an implementation partner, before go-live and at the first renewal.
| Area | Before signing | Before go-live | After go-live and at renewal |
|---|---|---|---|
| Ownership | Product owner appointed on the business side | Champions in each team, support model agreed | Product owner still in place, backlog of improvements |
| Processes | Target processes described (e.g. in BPMN), scope prioritised | UAT signed off by process owners | Process changes go through the backlog, not ad hoc |
| Architecture | Configuration vs code principles agreed | Automation strategy per object documented | No new Workflow Rules or Process Builder; technical debt tracked |
| Data | Data owners named, history scope decided | Two full test loads, reconciliation passed | Duplicate rules active, data quality reports reviewed |
| Integrations | Master system per object defined | Tested at production volumes with failure scenarios | Monitoring and alerting, owner for failed messages |
| Testing | QA role in the team plan | Regression suite for key processes | Regression run against each Salesforce release preview |
| Licences | Edition chosen on real needs, 3-year price assumptions | Licences activated in waves, not all on day one | Usage reviewed quarterly, unused seats reclaimed before renewal |
| AI and Flex Credits | Use cases and expected actions modelled | Pilot consumption measured | Consumption monitored monthly against allowance |
| Delivery model | Partner, in-house and augmentation options compared | Knowledge transfer plan agreed | Internal capability growing; dependence on one supplier reduced |
The key takeaways:
- Licences are the biggest cost over three years — about 55% in our example. Implementation quality determines whether that money buys anything.
- Since 3 September 2026, new customers buy Core, Advanced or Max at USD 195, 395 and 550 per user per month. Legacy editions keep existing pricing.
- A mid-sized implementation takes about 5,500 hours of a mixed team. Budget from roles and months, not from a single “partner” line.
- Configuration and Flow first, Apex where justified. Workflow Rules and Process Builder are out of support since the end of 2025.
- Data migration, integrations and testing decide go-live. They are also the first phases to be cut when time runs short — do not let them.
- Model AI consumption per process. The Flex Credit allowance in Core covers about 25,000 actions a year; heavy use of agents needs its own budget line.
At ARDURA Consulting we have been supporting clients in Poland, Europe, the Middle East and the USA for more than ten years. We are not a Salesforce partner. In Salesforce programmes we work alongside your team and the implementation partner you have chosen, providing staff augmentation — developers, QA engineers and integration specialists — and software asset management that keeps Salesforce licences and consumption under control after go-live.
If you are planning a Salesforce implementation or struggling with one that is already live, talk to our team. We can help you plan team capacity, strengthen testing and integrations alongside your partner, or review whether your licences match real usage.