① Journal · Syncsort (Precisely)
Syncsort (Precisely) renewals follow recognizable patterns from the buyer side: capacity based pricing that climbs with the machine, MFX repriced against a growing box, and Ironstream cross sold on the observability wave. Knowing the pattern is half the preparation. Here are five we see, and the lever on each.
Syncsort renewals are not random. They climb with the machine.
Across the Syncsort (Precisely, formerly Syncsort) renewals we sit on, the dominant theme is capacity based pricing. Precisely commonly prices Syncsort MFX, the high performance sort that sits on most IBM Z estates, against the capacity of the machine it runs on. The consequence at renewal is that a hardware upgrade or a higher rated configuration can lift the price even when your actual sort volume has not moved. The product did not change and your usage did not change, but the box did, and the renewal climbs with it. The renewal is decided by whether the price is tied to the capacity you actually use for the product or to the full rated capacity of a machine that grew for unrelated reasons.
The second recurring theme is cross sell on the observability wave. Ironstream forwards mainframe and IBM i operational data into Splunk, ServiceNow, Elastic, and Kafka, and is commonly licensed on a capacity basis tied to data volume or the machine. As enterprises push more mainframe telemetry into these platforms, Ironstream is increasingly presented at renewal alongside MFX, and ZPSaver is positioned as the offset that funds it through zIIP eligible offload. Each can be a real value case on its own, but folding them into one renewal hides the separate decisions. Pricing each product on its own capacity and use, and treating the DFSORT alternative to MFX as credible leverage, lowers the figure the renewal builds on. Read this with the Syncsort (Precisely) publisher hub and our Ironstream observability note.
Syncsort (Precisely) renewal patterns · what we commonly observe and the buyer side lever
| Pattern | What we observe | Buyer side lever |
|---|---|---|
| Capacity based repricing | MFX price climbs with the machine, not with sort volume | Tie price to used capacity, not full rated capacity |
| Hardware upgrade uplift | A bigger box lifts the renewal though usage is unchanged | Negotiate the price reset before or with the upgrade |
| Ironstream cross sell | Observability forwarding presented alongside the MFX renewal | Treat Ironstream as its own decision and value case |
| ZPSaver as the offset | zIIP offload savings positioned to fund the broader deal | Bank the offload savings separately from the renewal |
| Multiyear uplift | Annual escalators compounding across the committed term | Cap the uplift and price each year on its own |
These are patterns we commonly observe across Syncsort (Precisely) renewals, not statements of Precisely policy. Your specific entitlement, pricing model, and contract terms govern; treat the patterns as the questions to walk in with, validated against your own capacity and contract data.
Capacity based pricing lets the renewal climb with the machine even when your sort volume is flat. Baseline the capacity each Syncsort product actually uses against the full rated capacity it is priced on, and negotiate the price to the used figure. A bigger box bought for unrelated workload is not a reason to fund a higher sort license.
Price the capacity you use, not the box you bought.
Ironstream cross sell and ZPSaver offsets are commonly folded into the MFX renewal so the package reads as one number. Pull them apart. Value MFX on the sort workload and the DFSORT alternative, value Ironstream on its own observability case and data volume, and bank any ZPSaver offload savings separately rather than letting them quietly fund a larger commitment.
Three products, three decisions, not one package.
MFX competes directly with IBM DFSORT, and a credible evaluation of the alternative is real leverage on a capacity priced renewal. Scope the switching cost and performance difference in advance so the alternative is ready before the renewal, not improvised under deadline. The point is not necessarily to move; it is to remove the assumption that you cannot.
A ready DFSORT case changes a capacity priced deal.
④ Where the Syncsort number is won
Syncsort renewals climb with the machine. Tie the price to use, not the box. Separate the products, hold the alternative.
Typical reduction negotiated on renewal spend
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
Capacity based repricing. Precisely commonly prices Syncsort MFX against the capacity of the machine it runs on, so a hardware upgrade or higher rated configuration can lift the renewal even when sort volume is unchanged. The renewal turns on tying the price to the capacity you actually use rather than the full rated capacity of a growing box.
Ironstream forwards mainframe and IBM i data into Splunk, ServiceNow, Elastic, and Kafka, licensed on a capacity basis. As observability adoption grows it is increasingly cross sold alongside MFX. Treat it as a separate decision with its own value case. See our Ironstream observability note.
Baseline the capacity each product actually uses against the rated capacity it is priced on, validate the sort workload and any zIIP offload independently, value MFX against DFSORT as leverage, treat Ironstream as its own decision, cap the multiyear uplift, and start at least eighteen months out. See DFSORT vs Syncsort MFX.
Paying a capacity priced renewal against a bigger box when usage is flat, accepting Ironstream and ZPSaver folded into the MFX number, and walking in without a DFSORT case. Our license negotiation service ties the price to used capacity and our Syncsort (Precisely) audit defense holds the line on entitlement.
Related: Syncsort (Precisely) publisher hub · DFSORT vs Syncsort MFX · Ironstream observability angle · Syncsort (Precisely) audit defense · license negotiation
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →