When is one integrator cheaper than separate resellers?

The lowest discount on every line item does not make a support model inexpensive. When a company buys Microsoft, Oracle, and SAP from three resellers, the customer becomes the fourth integrator: it reconciles dates, settles responsibility boundaries, collects evidence of entitlements, and pushes for action when a failure crosses several systems.

One integrator usually wins on total cost when the products are connected, the customer's team is small, and downtime is expensive. Separate resellers cost less when the volume with each vendor is large enough to secure strong terms, the company already has mature software asset management, and the architectural boundaries truly match the contractual ones. The right comparison is not the discount percentage. It is the cost of owning the contracts and their risk throughout the term.

A discount does not answer the support cost question

Comparing proposals only by the final license total is wrong because that amount excludes the customer's work and the losses at system boundaries. One reseller may offer the best Microsoft price, another Oracle, and a third SAP. That table looks persuasive at the procurement committee. Six months later, finance reconciles three invoice formats, IT maintains three sets of entitlements, and procurement approves nearly identical documents three times.

The distinction between purchase price and support cost matters. Purchase price answers how much the entitlements, subscriptions, and support in a particular order cost. Support cost includes people, processes, mistakes, delays, surplus licenses, unplanned purchases, and management time. When those costs are missing from the calculation, they have not disappeared. They have moved into payroll and operational risk.

A discount also depends on its comparison base. A percentage off list price, a discount against the previous contract, and a reduction from the first proposal produce different numbers. Compare identical product codes, metrics, terms, currencies, taxes, support levels, and indexation rules. For subscriptions, record the monthly or annual term, the right to reduce quantities, and the cancellation window. For perpetual licenses, separate the right to use from annual support.

Use a practical test: ask every bidder to show the work it performs after the sale, not only the price. Who maintains the entitlement register? Who warns about changing terms? Who checks an order before placement? Who assembles evidence during a dispute? Who coordinates an incident across an application, database, and cloud service? An answer such as "we will give you the vendor's contact" means the customer will do the work.

A single supplier does not gain an automatic advantage. It may add its own margin, lack depth in one product, or turn convenience into dependency. Savings from one accountable party must therefore rest on measurable duties, not a promise to "handle every question."

Look at the seller's incentives as well. A reseller earns revenue from the transaction, so the customer needs an independent check before accepting a recommendation to renew the previous volume. The conflict is broader with one integrator because it may advise on architecture, sell licenses, and support the system. That arrangement is acceptable when the proposal discloses alternatives, assumptions, and the effect of each option on the integrator's compensation. Request a calculation with unchanged volume, another after optimization, and a list of positions from which the partner earns no revenue. A refusal to provide that breakdown matters more than the advertised discount.

Total cost needs its own model

The total support cost equals contract prices plus internal labor, external specialists, expected losses from errors, and the price of reduced competition. The model will not be perfect, but it is more honest than a three-percent discount in one column.

Use a horizon that includes at least one complete renewal cycle. For each option, count the hours spent by the license owner, procurement specialist, lawyer, architect, administrator, and financial controller. Add one-time work: entitlement inventory, contract transfer, account reconciliation, correction of registration data, and reporting setup. Multiply hours by the full internal rate, not an employee's salary.

A useful calculation form looks like this:

Do not pretend the risk estimate is mathematically exact. Use three scenarios: an ordinary year, a difficult renewal, and a serious review or incident. Record the basis for each figure. When a number has no basis, replace it with a range and show the point at which the decision changes.

Suppose three resellers save KZT 18 million on the purchase but require 900 additional team hours. At a fully loaded rate of KZT 18,000, that is already KZT 16.2 million. One urgent architecture review or a missed quantity-change window removes the balance. This is not a universal conclusion or a market statistic. It is a sample calculation that you should replace with your own rates and history.

Run a sensitivity check. If one integrator is cheaper only when every internal hour is valued too highly, the argument is weak. If the model still costs less after halving the labor estimate and assuming no major incident, the savings look durable. Separate resellers likewise deserve the contract when their price advantage covers realistic coordination expenses by a comfortable margin.

Allocate costs by cause, not only by department. An unnecessary subscription may result from a poor business forecast, a delay in disabling an account, or a contract restriction. When every expense lands in the general IT budget, the owner of the cause cannot see the price of the decision. For major changes, use an internal request in which the initiator records the system, users, term, environment, and dependent products. The license owner then returns a calculation for every vendor. The comparison between one integrator and several resellers will reflect the actual flow of work.

The renewal calendar must drive decisions, not reminders

A single calendar should define a sequence of decisions several months before a commitment date, not send a warning one week beforehand. Every contract has an end date, but the effective decision deadline comes earlier. Before it arrives, the team must collect demand, review usage, approve budget, obtain a proposal, and exercise any right to make changes.

Put Microsoft, Oracle, and SAP into one register even if you retain three resellers. At minimum, each record needs the business owner, technical owner, contract, program or metric, entitlement quantity, end date, notice date, currency, indexation, automatic renewal, reduction window, and evidence location. Record dependencies separately. An SAP project, for example, may change demand for database rights, server capacity, and user subscriptions.

You can keep a machine-readable register fragment beside the ticketing system:

contract: SAP-prod-01
business_owner: finance
technical_owner: erp-team
renewal_date: 2027-03-31
decision_deadline: 2026-12-15
quantity_change_deadline: 2027-01-31
evidence_folder: contracts/SAP-prod-01
dependencies:
  - oracle-db-prod
  - microsoft-identity
status: usage-review

This fragment prevents a familiar failure: the contract still runs, but the right to reduce volume has already expired. The decision_deadline field starts analysis before the commercial proposal, and dependencies require the owner to check adjacent products. Take the values and dates from your own agreements rather than copying the example.

Set five control points for every renewal. First, confirm entitlements and contractual constraints. Next, measure actual use and the project forecast. Then approve the target configuration, run the competitive request, and only then place the order. A commercial proposal obtained before usage analysis turns last year's structure into the default requirement and preserves waste.

One integrator saves money when it maintains the common calendar and raises connected decisions early. Sending three invoices through one legal entity changes nothing. With separate resellers, appoint an internal owner for the consolidated calendar and give that person authority to stop an order. Otherwise, each supplier will optimize only its own date.

Hold a short monthly calendar review with system owners, procurement, and finance. The group does not need to discuss every license. It reviews decisions in the near horizon, new projects, accounting discrepancies, and contracts without confirmed budgets. Record the decision, assumptions, and next review date after the meeting. That history helps when an employee leaves and explains why a quantity rose or why the team did not align one term with another.

A license review starts with entitlement evidence

Paid invoices are not enough during a review. The customer must connect contractual rights to actual deployment, users, hardware architecture, and changes during the period. A reseller can help assemble commercial history, but the licensee remains responsible for accurate environment data and compliance unless the contract expressly states otherwise.

Separate entitlement verification from usage measurement. Entitlement asks what the organization purchased and under which conditions. Usage shows what is installed, assigned, running, or accessible. Teams often mix these datasets and then try to prove an entitlement with a console screenshot or prove use with an old specification. They are different types of evidence, and the gap between them creates the risk.

SAP's official documentation describes measuring users and software engines with USMM, while LAW 2.0 consolidates results from multiple systems. Practice adds an important qualification: a valid measurement file does not prove correct user classification or a complete contract archive. Before sending the result, check roles, duplicates, technical users, excluded systems, and the relationship between user types and the terms of the specific contract.

Oracle License Management Services describes LMS as the Oracle authority that can verify licensing requirements for Oracle programs. That does not mean a customer should wait for a formal review. Assess architecture changes, virtualization, workload moves, and new access paths before implementation. Keep the written reasoning and the version of the terms used in the analysis.

For Microsoft, cloud assignments, subscription dates, and order history show only part of the position. Match them to identities, devices, development environments, servers, and external-user rights where those matters apply to your products and agreements. Do not move a rule from one agreement to another from memory. The applicable text remains your agreement and the official terms for the relevant program.

One integrator helps during a review when it already maintains a shared entitlement catalog and can separate a question by vendor without giving contradictory answers. Do not give it the only copy of the archive. The customer must retain specifications, orders, confirmations, correspondence about exceptions, measurement results, and an architecture decision log in an exportable format.

Establish an internal protocol for responding to a review request. One person registers the request and its contractual basis, legal determines the scope of the obligation, the technical team preserves source data, and the license owner reconciles it against entitlements. Nobody sends an export directly from email without checking its contents and period. The protocol should not obstruct cooperation with the vendor. It protects accuracy because a rushed incomplete export creates unnecessary questions, while an unexplained edited file damages trust.

Escalation breaks at contract boundaries

A complex incident rarely respects the procurement structure. A user cannot enter SAP, the log reports an Oracle database error, and authentication depends on a Microsoft service. Each component may operate within its documentation while the business process remains stopped.

The typical failure with three resellers unfolds predictably. Application support asks for proof that the database is available. The database supplier asks for a client trace and confirmation of the network route. The cloud partner checks authentication and closes its ticket because sign-in succeeded within its service. The customer manually repeats the replies, loses timestamps, and explains the business impact three times.

The problem is not the number of phone lines. Nobody owns the complete incident hypothesis or has a duty to bring the technical specialists together. Require joint escalation rules before purchasing:

1. One customer incident receives a shared identifier, priority, and impact statement.
2. A coordinator assembles the timeline, versions, changes, and evidence from every domain.
3. Suppliers keep their tickets open until the coordinator confirms a workaround or cause.
4. A dispute about fault does not stop diagnosis or log preservation.
5. After recovery, the coordinator issues one review with actions and owners.

Put these requirements in the contract and operating procedure, not in a sales presentation. State acceptance time, update frequency, roles, communication channels, rules for involving a vendor, and the priority escalation path. Agree separately on who turns a technical issue into a commercial escalation if support is unavailable because an entitlement was registered incorrectly.

One integrator saves time when it accepts coordination responsibility regardless of which component caused the incident. If its SLA covers only forwarding the ticket to the appropriate reseller, the customer is paying for another mailbox. Under the separate model, a strong internal service function or an independent service partner can own coordination, but its cost belongs in the comparison.

Agree on one translation between participant priority scales. "Critical" for the customer may mean a payroll run has stopped, while one supplier's rules reserve that priority for a complete production outage. The procedure should describe business impact, affected users, workaround availability, and the operation's deadline. The coordinator adds these facts to every related ticket and updates them as the situation changes. Escalation then rests on observed impact rather than an argument about the level's name.

The responsibility matrix must survive a dispute

The phrase "single point of contact" means nothing without a list of results, owners, and deadlines. A useful responsibility matrix shows who makes a decision, who performs the work, who contributes, and who receives information. In licensing, connecting roles to specific artifacts matters more than debating a neat acronym.

Name owners for the entitlement register, renewal calendar, demand forecast, usage measurement, architecture-change review, commercial comparison, order placement, document storage, and cross-vendor escalation. Every task needs one person accountable for its outcome on the customer's side. The integrator may perform most operations, but it should not approve business demand or accept risk for the organization.

Test the matrix against four awkward situations. Who is responsible when a reseller fails to warn about the reduction window? Who corrects an order with the wrong metric? Who pays for an urgent purchase caused by bad advice? Who presents one agreed position when two vendors interpret a shared architecture differently? When the answer is "we will discuss it if it happens," the contract leaves the most expensive risk with the customer.

Define the boundaries of advice separately. An integrator can prepare a licensing analysis, but the customer's lawyer must participate in legal interpretation of the contract. A technical architect confirms the actual design, a product owner confirms user roles, and procurement confirms commercial records. This split does not blur accountability. It stops one inaccurate assumption from passing through the entire process.

Ask the supplier for its monthly report template before signing. It should show upcoming decisions, quantity changes, open discrepancies, vendor tickets, evidence status, and risks with named owners. An invoice list does not qualify. The team needs a working instrument for making decisions.

The recommendation to make one supplier "responsible for everything" is popular because it sounds simple. It is wrong without authority over other participants and a measurable outcome. Accountability requires data access, the authority to convene the parties, a response deadline, and a financial consequence for an unperformed duty.

Check whether a supplier can satisfy a metric formally while failing the intended result. It can send a notice on time without stating the last reduction date. It can accept an incident in five minutes without assigning a technical coordinator. It can export a register with no links to supporting documents. Add acceptance criteria to every SLA: mandatory notice fields, the content of the first status, export format, and an allowed proportion of entries without evidence. These details reduce acceptance disputes much more effectively than a general quality promise.

Separate resellers work when the internal function is mature

A separate model can cost less and perform better when the organization can integrate commercial and technical domains itself. It is a reasonable choice for a large customer with dedicated Microsoft, Oracle, and SAP specialists, a software asset management system, a contract archive, and a service function that runs cross-system incidents.

The first case for specialization is depth. A reseller with substantial business in one vendor may understand its licensing program better, move through its support process faster, and offer a competitive price. The second is negotiation independence: poor work in one area does not block the others. A third appears when purchasing cycles differ and combining contracts creates no operational connection.

Spending scale alone is not enough. The separate model requires internal artifacts and discipline. The organization needs a unique contract identifier, a normalized product catalog, a connection between entitlements and consumption, a decision calendar, a recommendation log, and an escalation procedure. If the data lives in three account managers' mailboxes, the function is not mature even when the budget is large.

Check whether the architectural boundaries are independent. If SAP runs on Oracle, uses Microsoft identity, and depends on a shared server platform, the suppliers will still meet during changes and incidents. If the products support different legal entities, teams, processes, and infrastructure, coordination costs less. The contract structure should resemble the actual responsibility structure, not the procurement department's organization chart.

A hybrid model can also make sense. The customer selects the best resellers for transactions and assigns the register, calendar, architecture control, and escalations to one service integrator. This retains price competition but adds a fourth contract and requires a precise separation between advice and sales. Otherwise, the service integrator becomes another intermediary without authority.

Do not make the number of suppliers a procurement objective. The objective is predictable cost and controlled risk. When the internal team already performs the integration work faster than an outside partner, there is no reason to pay for duplication. When people carry that work as an invisible extra duty, its cost is almost certainly understated.

A transition must not start by moving orders

Changing the model starts with an inventory of entitlements and obligations, not an email naming a new reseller. Otherwise, the customer moves only active purchases and leaves history, exceptions, and unresolved discrepancies with the former participants.

Define the scope first: legal entities, countries, contracts, accounts, subscriptions, perpetual rights, support, and open tickets. Then collect source documents and exports. For every object, record its source, owner, reconciliation date, and discrepancy. Do not correct everything at once. Preserve evidence unchanged first, then create a normalized working copy.

The next stage is parallel reconciliation. The new partner builds the entitlement catalog while technical teams confirm deployment and use. Procurement matches invoices and orders, legal checks transferred duties and notices, and system owners confirm future demand. Every discrepancy becomes a separate task with a decision, owner, and deadline.

Check four outcomes before switching:

• every renewal in the nearest cycle has a confirmed owner and decision deadline;
• open tickets retain their history and escalation path;
• the new partner has the required registrations and access, while old access is removed only after verification;
• the customer has an export of the register, documents, recommendations, and contacts.

Run a practice escalation with a safe example. Submit a request that affects two products and observe who creates the shared timeline, how the parties exchange evidence, and when a manager receives status. A rehearsal exposes empty roles more cheaply than a live outage.

Do not force every transition onto one date for the sake of a tidy project. Move domains when they are ready and respect vendor windows. During the transition, keep one decision log visible to the old supplier, new supplier, and customer within their respective roles. Close each domain with a signed data handover, not only a service acceptance certificate.

Exit terms and measurable indicators secure the choice

Choose the model that costs less at your coordination volume and remains manageable during a dispute. Issue the same request to a single integrator and to separate resellers: one entitlement specification, one list of service duties, and the same review and incident scenarios. Proposals with different scope cannot be compared.

Divide the scoring table into price, expertise, process, and control. Price covers the discount, indexation, currency risk, urgent orders, and exit cost. Named specialists and a response to the test scenario demonstrate expertise. Sample calendars, reports, and tickets demonstrate process. The right to export data, replace a participant, and inspect completed work demonstrates control.

In the contract with one integrator, require line-level price transparency, protection against unjustified product-code substitutions, decision notice periods, a shared register, cross-vendor coordination, and data transfer at exit. In separate reseller contracts, require compatible formats, participation in shared escalation, and delivery of evidence to the internal owner. Under either model, the customer retains direct vendor contact wherever the program terms allow it.

GSE works as a system integrator and supplies Microsoft, Oracle, and SAP solutions, so it can bring the software together with infrastructure and ongoing support. Evaluate such a proposal against the same strict criteria: one calendar, transparent accountability, exportable data, and demonstrable coordination.

Put a small number of hard-to-game indicators in the contract: the proportion of renewals with an approved decision before the deadline, time to assign a cross-vendor incident coordinator, orders returned because of errors, time to close register discrepancies, and completeness of the monthly export. Average response time says little about the result by itself because an automated email also counts as a response.

Exit terms matter on the day of entry. The customer must receive the register in a readable format, copies of commercial and technical confirmations, a list of open issues, recommendation history, and escalation contacts. If the supplier treats these data as its internal property, a future change will be expensive regardless of today's discount.

The decision does not need a slogan. Choose one integrator when it removes measurable coordination work and accepts responsibility for system boundaries. Keep separate resellers when the internal function already maintains common control and the price and expertise gains from specialization exceed its cost. Many organizations know the most expensive arrangement: three suppliers, no internal owner, and confidence that integration will happen by itself. Recheck the calculation annually because system volume, team expertise, and contract terms change.