Who to hire for PredictionIO on Salesforce

Three kinds of people land on a page like this one. The first has an engine running somewhere in their estate that a developer set up years ago, and a nervous infrastructure team who would like it gone. The second wants predictions from their Salesforce data, such as which customers will lapse or which products to suggest, and has read that Salesforce once bought a machine learning server. The third saw a 2016 headline and wonders whether it means something now. The right hire is different for each, so this page is organised around them and not around a generic partner checklist.

First, the facts that apply to all three. In February 2016 TechCrunch reported the acquisition and described the product as "MySQL for machine learning." The terms were not disclosed, the community was said to include some 8,000 developers and 400 apps, and the report ended with a promise that is the sentence every older document repeats: "PredictionIO’s tech will remain open source and free to use, while the team works on evolving the project into a self-sustaining community." What happened next is on the Apache side. The project's own status page says: "PredictionIO became a Top Level Project in October 2017, retired in September 2020 and the move to the Attic was completed in April 2021." Its website opens with "This project has retired." The code remains in a read-only repository, which means you can still read it and still run it, but nobody maintains it.

That settles the first question. PredictionIO is not a Salesforce product, it was never a licence line on an order form, and there is no vendor to call. The history sits on What happened to PredictionIO. It is also a different story from the earlier RelateIQ and SalesforceIQ acquisition, which produced a product that Salesforce then retired itself.

#Situation one: you run an inherited engine

If an engine is serving predictions today, you do not need a Salesforce partner first. You need a data engineer who can read Scala and operate Spark, and who will treat the engine as a legacy system to be understood before it is replaced.

Apache's description of the product is useful here: "Apache PredictionIO® is an open source Machine Learning Server built on top of a state-of-the-art open source stack for developers and data scientists to create predictive engines for any machine learning task." The documentation breaks an engine into four parts, known as DASE: a data source, a data preparator, one or more algorithms, and a serving layer, with an Event Server that collects the data and engine templates for common cases such as recommendation. Ask any candidate to explain DASE and then to apply it to your engine. A person who can say which template your engine started from, which components were customised, and where events come from has done this work.

Then ask about the stack. The project describes a bundled install with Spark, HBase and Elasticsearch, which means a retired platform is sitting on other platforms that have their own support lifecycles. Retiring the engine is as much an infrastructure exercise as a modelling one. Inventory what depends on its predictions, what events feed it, how often it retrains, and who notices when the output drifts.

There is also a risk argument that a finance or security lead will grasp quickly. A retired project no longer ships releases, so any weakness found in its own code becomes yours to patch or to live with. That does not make the engine dangerous overnight, but it moves the engine from a maintained dependency to an unmaintained one, and your risk register should say so. The sensible pressure is a dated plan to move off it, not a panic. Ask any candidate how they would sequence that plan so that the engine keeps serving until the replacement has matched it over a full business cycle, including the awkward weeks such as year-end or a major campaign.

#Situation two: you want predictions on Salesforce data

If your goal is to predict something with Salesforce data and nothing has been built yet, do not look for PredictionIO expertise at all. The current Salesforce home for this is AI Models, which Salesforce's learning material describes this way: "As of spring 2026, Einstein Studio has been rebranded to AI Models." The same module says you can create models in AI Models or connect predictive models built in external platforms, naming Amazon SageMaker, Google Cloud Vertex AI and Databricks. That bring-your-own-model route is the closest modern descendant of what PredictionIO offered, in the sense that data scientists keep their tools while Salesforce supplies the data and activation.

The hire for this is two people, even if they come from one firm. A Data 360 consultant gets the data into a shape a model can learn from and gets predictions back to the people and processes that use them. A data scientist, or a machine learning engineer, chooses and validates the model. Look for the Salesforce Certified Data 360 Consultant credential on the first. There is no Salesforce credential that proves the second, so ask for a model they built, the metric they used, and an account of a time it performed worse in production than in testing.

Be sceptical of any partner who proposes to rebuild PredictionIO inside Salesforce or on a cloud server because "the code is open source and free." The code is free. Running it is not, and a retired project means you carry the maintenance yourself. That is a decision you can make with open eyes, but it should be a decision, not a default.

A word on the Salesforce admin's role in situation two. Many predictions projects stall not on modelling but on delivery: the score exists, and nobody opens it. Insist that the partner names the screen, report or flow where a user will see the prediction, who that user is, and what they are expected to do differently. A churn score nobody acts on is a cost, not a capability, and a partner who cannot describe the action has built a model in search of a job.

#Situation three: you read the headline

For readers who only saw the 2016 story, the useful conclusion is short. Salesforce bought a team and a machine learning server to build intelligence into its clouds, said the open-source project would stay free, and then the project went its own way and eventually retired. Today's Salesforce predictive and agent features have their own names and their own documentation. If someone proposes to "implement PredictionIO on Salesforce," ask them to describe in plain language what the outcome will be. If they cannot, the conversation ends there.

#A realistic first engagement for each situation

For the inherited engine, start with a two-week inventory ending in a written decision: replace, retire or freeze. The document should list every consumer of the engine, every data source, a replacement option for each prediction, and a fallback if the replacement does worse. Do not agree to a build before you have read that document.

For new predictions, start with one use case and one outcome that has historical data. Choose something with a clear label, such as an opportunity that was won or lost, and a clear consumer, such as a list a manager looks at weekly. The first phase should deliver a baseline, a model, a measured comparison and a decision about whether to go further. A partner who promises accuracy before looking at your data is guessing.

#Red flags

The loudest is anyone who sells a "PredictionIO licence" or "PredictionIO support from Salesforce," because neither exists. Be wary of a partner who wants to deploy a new engine on the retired code and who has no plan for the Spark, HBase or Elasticsearch components beneath it. Be wary of proposals that skip the data question and jump to algorithm names, because a prediction is only as good as the history behind it. And be wary of a migration plan that has no way to compare the old engine's output with the new one's over the same period, since without that comparison you cannot tell whether the replacement is better, worse or just different.

#Ten questions to ask

1. Which engine template, if any, was our engine built from, and what would you check to confirm it?
2. Explain the four DASE components and show where each would live in the replacement.
3. How will you extract and validate our historical events before anything is switched off?
4. What happens to the stack beneath the engine when the engine itself is retired?
5. How will you compare the old and new predictions over the same period, and who signs off the difference?
6. If we want predictions on Salesforce data, would you build the model in AI Models or connect one from another platform, and why?
7. Which Data 360 objects would the model learn from, and how do you handle missing history?
8. How do predictions return to a Salesforce user, and who acts on them?
9. How will you detect that a model has drifted, and who is told?
10. What would make you advise us not to build this at all?

#Checking references and evidence

References matter most on the data side. Ask for a customer where a legacy prediction service was replaced, and ask what the comparison period showed. Ask to see the plan for monitoring drift, not the model. For the Salesforce side, look at Trailhead credentials, and ask the partner to show a connected-model or in-platform prediction on a demonstration org with the data, the score and the action visibly linked.

Be cautious about firms that claim "machine learning experience" without a single example you can ask questions about. The question to pose is simple: what was the label, how did you know it was right, and what happened after launch?

#Commercial models and the statement of work

Buy the inventory as a fixed short piece of work with a written decision at the end. Buy the replacement build, once chosen, against a scope that lists the consumers to be switched, the datasets to be migrated and the comparison period, with acceptance based on the comparison. For a new prediction project, fix the first phase and leave the second open.

The statement of work should name the use case, the label, the data sources, the model owner, the way predictions reach users, the monitoring owner after handover, and a rollback plan. Leave out promised accuracy. Licence questions belong on PredictionIO Salesforce licence cost, which explains why open source has no licence to buy, and project scoping sits on PredictionIO Salesforce implementation cost.

#When you can skip a partner

If your engine is a lightly modified template serving one internal consumer, and your team can read Scala, you may be able to retire it yourself with a careful comparison period. If you want a simple prediction from clean Salesforce data and have a data scientist in-house, the AI Models route may be a few weeks of internal work. Bring in a partner when the engine is bespoke, the consumers are many, or the data needs unifying before it can be used. The wider migration question is covered on Should I migrate from PredictionIO, the data flow on Integrating PredictionIO with Salesforce, and the build-side view on PredictionIO, machine learning, and what 2016 did not sell you. The Apache project's own status is on its Attic page.