On a Friday before a NetSuite go-live, Jay Kiefer had a problem with a very precise shape: roughly 1,800 configuration elements, accumulated over a year, had to leave a development environment and arrive in production by the following week. Kiefer, a principal consultant at PCG, knew what the conventional route might mean. The built-in bulk tools could move some of the work. The rest might have to be rebuilt by hand, with duplicate objects and fresh testing as the unwelcome souvenirs.
The short version
- Salto turns business-app configuration into versioned files, then helps teams compare environments and deploy selected changes.
- PCG says it moved all but 26 of those 1,800 NetSuite elements in about two hours.
- Customers include application teams and consultants working with Salesforce, NetSuite, Jira, Zendesk and Okta.
- Its public pricing is tied to configuration size, with unlimited users and non-production environments.
The panic was not really about the number 1,800. It was about the distance between a tested sandbox and a live system. Recreating a setting by hand in production does not move the tested object; it makes a new one that looks like it. Kiefer even considered building directly in production. That would have solved the calendar problem by handing the risk to the customer.
Then PCG tried Salto. Kiefer said the tool clicked when he understood it as a comparison of two sets of files. It surfaced dependencies, letting him decide what belonged in the deployment and what did not. He finished the bulk of the move in roughly two hours. PCG reports a 95% reduction in production deployment time from its previous process. This is a customer case, not a universal benchmark. Its interest lies in the mechanism: the software made the hidden shape of the change visible.
“Once I understood it was essentially comparing two different sets of files, it made sense.”Jay Kiefer, principal NetSuite consultant, PCG
The settings nobody calls software
A modern company may run sales in Salesforce, finance in NetSuite, support in Zendesk and work management in Jira. These are not blank utilities. Each is remade by its users: fields, workflows, permissions, triggers, forms, scripts and rules. The customizations are often the business process itself, translated into a thousand little switches. Lose track of one and the resulting error looks less like a broken setting than a broken company habit.
Software engineers solved an analogous problem years ago with source control, code review and release pipelines. Salto’s founders - Rami Tamir, Gil Hoffer and Benny Schnaider - came from infrastructure businesses associated with virtualization and cloud migration. They founded Salto in 2019 to bring that discipline to business applications. The company calls its representation language NaCl, for “Not Another Configuration Language,” a name that gently admits how many such languages already exist.
Salto connects to an application, fetches its configuration through an adapter and translates it into text files. A team can search those files, see what depends on what, compare a sandbox with production and move chosen changes. Git integration supplies history and pull requests; validation and conflict checks catch some mistakes before release. The method suits admins who want a visual interface as well as developers who want code and CI tools. That overlap is its commercial point: the people responsible for a business system do not all work in the same editor.
A release process for fields and workflows, not only code.
A test can pass for the wrong reason
At Intrepid, a team building a Jira Service Management application kept four Jira environments: test, QA, user acceptance testing and production. The configuration of each instance had to accompany the application through the release cycle. Manually recreating workflows, fields and automations made drift likely. CTO Alexander Preston described the trap neatly: a test could pass in QA because a dependency existed there, then fail in production because the dependency had never arrived.
Intrepid says Salto cut its Jira deployment time by 80% and testing time by 50%. More revealing than either percentage is the complaint underneath it. A passing test is evidence only about the environment in which it ran. Teams can copy the lesson without buying a particular platform: inventory the settings that a feature requires, compare environments before release, and make the promotion path explicit. If configuration changes are left as tribal knowledge, the test suite is being asked to certify the wrong thing.
For Riskified, the reason to keep a record was different. Its NetSuite team needed to explain changes to auditors. It connected Salto to production and a GitHub repository, tying changes back to Jira requests. The useful output was not just a list of changed fields. It was the answer to the awkward follow-up: who asked for this, when did it move, and why?
The price of a visible change
Salto sells a hosted subscription. Its pricing page says customers pay according to the applications managed and the size of their production customizations, while users and non-production environments are unlimited. The help center gives a numerical example: 1,000 billing tokens at $1.25 per token per month comes to $15,000 a year. Tokens represent counted configuration elements, with application-specific rules; automation and enterprise controls can add to the bill. A buyer must inspect its own production instance to know the relevant count.
The company’s help center uses this example. It is not a quote for every customer or application stack.
That choice of meter is revealing. A seat-based plan might penalize the company for letting more people review a change. Salto instead puts the cost near the size of the configuration under management. The trade-off is that a sprawling, customized system can become expensive even with a small team. It also means a clean pilot should start with a bounded application and a known set of elements, so the value and the count can be observed together.
The alternatives are familiar: each application’s own administration and deployment tools, hand-maintained scripts, or specialist DevOps products for one platform. Salto’s claim is breadth. A quote-to-cash process, for example, may pass through a CRM, a billing system and an ERP. No one vendor’s native release screen sees that entire route. Salto has expanded its adapters over time, and its public material names Salesforce, NetSuite, Jira, Zendesk and Okta among the systems it can manage. The actual fit still depends on the adapter’s coverage and the customer’s configuration.
Now the applicant is an agent
In 2025 Salto introduced Pipelines, a visual way to track where a work item sits across development, testing and production, including changes that need to be promoted back into skipped environments. In 2026 its documentation added AI-assisted implementation: an agent can draft a configuration change inside Salto’s workspace, ready for review and deployment. The new actor is fast; the old question remains. What else does this field touch?
Salto says hundreds of enterprise application teams use its platform. It raised $27 million in 2020 and $42 million in 2021. Neither figure proves that every deployment is painless. The stronger argument is more ordinary: a diff lets a human ask a better question. In PCG’s 1,800-element Friday, 26 elements did not make the trip. That is not an embarrassment. It is what a controlled deployment can look like when the team can finally see what it is moving.