Should I migrate from PredictSpring

A retail lead staples a website sitemap to a brief titled migrate PredictSpring. The sitemap is the shop a customer uses from a sofa. PredictSpring is the till a colleague uses in a store. The two can share a product code. They do not share a transaction. Migrating the till by rebuilding the website mixes two programmes because both can sell a shirt. This page decides whether the counter should move, and it leaves the storefront where it is.

PredictSpring is retail point-of-sale software. Salesforce completed the acquisition. The purchase did not hand you a new website, and it did not retire the commerce product you already run. If that product is B2C Commerce, it remains the storefront it already is. PredictSpring does not replace B2C Commerce. The only sentence this page quotes from the announcement is the completion line. "Salesforce completed its acquisition of PredictSpring on September 12, 2024."

#Should you migrate

Migrate the counter when you can describe one receipt without opening the website. The customer is in a named store. They pay with a tender finance already settles. Stock for that product moves in a location you can name. If the shop network drops, someone already knows what the colleague may still sell. That receipt is a design you can migrate. A sitemap is not.

Do not migrate because the brands now share an owner. Ownership is not a cutover. The cited page does not publish a shutdown date, so you are not late against a quarter this page invented. Stay on the till you trust until the receipt fields, the roles, and the offline habit are written down. A web replatform can be a real project. It is not this decision.

Count the pilot stores yourself. This page will not guess how many doors you have. One store after close, with a way back, is a migration you can judge. All stores on one weekend is a launch. Call it what it is.

#A receipt is not a web order

A sale at the counter produces a store transaction: store, register or device, colleague, lines, tender, tax, and an inventory event. A purchase on the website produces a different record, created from a basket. Those records meet only where you write a mapping, for a crossing you have named. A web return accepted in store is a crossing. A store pickup is a crossing. "They are both orders" is not a mapping.

Until that mapping is written, do not load till receipts into the commerce order book, and do not treat a web order number as a receipt the till already understands. The colleague at the counter cannot fix a website order by taking a payment, and the website cannot reprint yesterday's till tape because a product code matched. Write the boundary in the brief. One crossing is a line. Integrate commerce is a second programme.

#What the software is now

Salesforce owns PredictSpring. The completion date is 12 September 2024. What the software is now is retail point of sale. It is not a replacement for B2C Commerce, and it is not a screen this page will draw. The cited page does not publish a price. Your licence, if you pay one for a retail product, is on your contract.

If stores still log into the till under the old brand, that login is an operational fact for the store operations lead. This page will not redraw it. If you have no till, do not invent a counter in the plan so a commerce slide has a second box. What you have, if you run B2C Commerce, is a storefront. What you would be migrating, if you migrate, is the receipt.

#The three pages

This page answers whether you should migrate, what the software is now, how a receipt compares with a native commerce order, and which alternatives sit unranked. It does not price devices, and it does not narrate a storefront rebuild.

The implementation page is PredictSpring and Commerce Cloud. Use it for stores, receipts, inventory events, and the person who owns an exception at the counter. The what-happened page is What happened to PredictSpring. Use it for ownership, the date, the blank price, and the absent end date. The integration page is Integrating PredictSpring with Salesforce. Use it when the receipt and the web order must meet, and only for the crossing you can name. Do not ask one page to do the other two jobs.

#Versus the order B2C Commerce already keeps

A B2C Commerce order already records a purchase made on the storefront. It holds line items drawn from the catalogue, quantities, a shipping method and address, a payment, tax, and an order number the website can show the customer. The storefront is the system of record for that order until you deliberately hand a step to the shop, such as a pickup you have specified. That is the native commerce object. It already answers what the website sold.

A Salesforce sandbox does not clone that system. A sandbox copies the core org you choose to refresh. It does not copy the B2C Commerce instance, its catalogue, or its orders. Refreshing a sandbox and calling the result the shop will leave you with metadata and no storefront. Do not migrate the website by refreshing a sandbox.

Only after those two facts does the comparison count. PredictSpring is the till. A store transaction is not a B2C order. It becomes related to one when the mapping is written, field by field, for a named crossing. Product codes may match and still leave the tender, the store, and the inventory location unmapped. Matching a code is not the mapping. The mapping names which system owns the web order, which system owns the receipt, and which event is allowed to cross.

Native commerce already shows the web order. It does not know your drawer counts, your offline habit, or which colleague may void. Those are till facts. Bringing them into a storefront quote will price the wrong object. Keep the comparison to one sentence you can defend. The website order already exists in B2C Commerce. The receipt is a different transaction until you write how they meet.

#What you must not move

Do not replace B2C Commerce with the point-of-sale project. Pages, checkout, and the catalogue stay on the storefront quote. Do not treat a sandbox refresh as a clone of that storefront. Do not create commerce orders from till tapes because both files contain a product code. Wait until the mapping says which receipt is allowed to create or update which order, and what happens when the product is not on the shelf.

Do not migrate hardware, a new acquirer, or a loyalty scheme inside this decision. Each can be real. Each is a different owner. A blended commerce number hides which programme you accepted.

A migration that flattens discounts, voids, and drawer access into one shared login has removed a control to make the pilot easy. Write the roles you already use. Write the offline habit beside them: what a colleague may still sell, what they must refuse, and how an offline sale is identified when the network returns so you do not create it twice. A till that assumes the shop is always online will be priced as if that were true. The first interrupted morning will show that it is not.

#Alternatives, without a rank

People search for alternatives after the acquisition, and for an alternative on AppExchange. This page has not been shown an AppExchange listing. It will not invent a listing, a rating, or a rank.

One way is to keep the till you run and leave B2C Commerce as the storefront it already is. Another way is to move one pilot store's receipts, tenders, and inventory events, with the web order still owned by the storefront except for a crossing you wrote down. Another way is to change the storefront under its own quote, without calling that change a PredictSpring migration. Another way is to evaluate a different point-of-sale product on your own criteria, outside this page.

None of these is placed first. The gate is whether you can describe a receipt, and whether you are being asked to rebuild a website in the same line. If the website is in the line, you are not looking at this migration. You are looking at two.

#A walkthrough you can finish on paper

A migration walkthrough here is not a click path. This page has not been shown a screen. Write one receipt as fields. Write the pilot store. Write the tenders you already settle. Write the inventory system, the location, and the event for a sale, a return, and a transfer. Write the offline habit. Write any single crossing to a web order, and write that the storefront still owns that order until the handoff you defined. Write that a sandbox refresh is not a copy of B2C Commerce. Stop on a blank line.

Take the receipt to the implementation page. Leave price and shutdown on the what-happened page, still blank. Take the crossing to the integration page. If a proposal adds a sitemap, a search rebuild, or a sandbox that "includes commerce", send that line back.

#How the pack goes wrong

The pack fails when one number is labelled commerce. Inside it sit a website, a till, a sandbox refresh, and a search project nobody scoped. Finance cannot tell which programme they accepted. Split the number before you compare proposals. The till line names stores and receipts. The storefront line, if you even have one this quarter, names pages and checkout on its own page. A third line for search does not belong on either. Search ranking is a different neighbour, and it is not this migration.

#The first trading days

If you move one store, judge the days by exceptions, not by a sales total. Voids. Offline sales that appear twice, or not at all. Tenders the provider did not recognise. Inventory that landed in the wrong location. A web order that the till has started to own without a mapping. That last one is the boundary failing. Stop and restore the storefront as the owner of the web order before you open a second store.

Bring the table to the meeting. If the website is inside the till row, split the programmes before anyone prices them. The implementation page can price a receipt. It cannot price a storefront that a sandbox did not copy.