Should you migrate from m3ter

A product manager hears that Salesforce bought a metering company and asks, in the same meeting, what to charge per API call. Someone writes a number on the whiteboard because the silence is uncomfortable. The number is not in the announcement. It is not in the customer contract. It is now in a photo of the whiteboard, which is how a fictional price becomes internal policy.

This page is the decision page. Should you migrate. What the software is now. How a meter compares with a native product quantity. What else you could do, with no ranking. It will not name a package on AppExchange, and it will not give m3ter an end date.

#Should you migrate

Usage is a count of something a customer did. A price is a rule that turns a count into money. Migrating usage by inventing a price skips the rule and sends the money anyway. Do not migrate usage by inventing a price. If the brief needs a rate before anyone can say what is being counted, the answer is no.

A meter is not a Salesforce product quantity until the mapping is written. Product quantity, on an order or a quote, is a number Salesforce already understands: how many of a named product. A meter might count API calls, seats active in an hour, gigabytes, or something your engineers named in a system the CRM has never seen. Until you write which meter becomes which product, and in which unit, the quantity field is the wrong destination. Loading counts into it because the field exists will bill the wrong thing with a straight face.

A careful yes looks different. You name the meter, the unit, the customer, and the rating rule that already exists in a contract. Then you map that meter to a product you have already created. Then you decide who may change the rule. That sequence is a migration of meaning. A spreadsheet of counts with a guessed rate is not.

The walkthrough is that sequence, written as gates. No gate opens because the acquisition completed. The date is 1 July 2026. Your price list is a different document, with a different owner.

#What m3ter is now

The sentence this page quotes from the close notice is: "Salesforce completed its acquisition of m3ter on July 1, 2026." The date in Australian order is 1 July 2026. Same day. m3ter is metering and rating for usage-based pricing, aimed at Agentforce Revenue Management.

Metering is how you count what a customer used. Rating is how a count becomes a charge under a rule you wrote. Usage-based pricing is the commercial shape those two activities serve. The aim is Agentforce Revenue Management. That is a direction. It is not a statement that every Revenue Cloud org gained a meter on the day of the close.

Owning a metering company does not own your price. The price a customer pays for usage is a decision your company makes, often per product, often per contract, with a start date. Salesforce buying the company that counts and rates does not write that decision for you. A partner should not write it in the margin of a technical proposal either.

What the software is now stops at metering and rating, aimed at that revenue product. The notice does not publish a purchase price, a licence fee, a price per API call, or a shutdown date. "Went live", in the sense that your org now rates calls, is a claim this source does not make. Your order form says whether you have the product. A news date does not.

#Write the mapping before the quantity

Take one meter and refuse to generalise until it is boring. Suppose the meter counts successful API calls for a named customer in a calendar month. The mapping says which Salesforce product represents that count, which unit the quantity uses, and which rating rule applies. If any of those three is missing, the quantity stays empty. An empty quantity is a truthful state. A guessed quantity is a bill.

Write the rating sentence in words a finance partner can read without an engineer in the room. "Each successful call is priced at the rate in schedule B of the order form dated on the account." If schedule B does not exist, you do not invent schedule B to keep the invoice calendar. You stop. The invoice waits. That delay is cheaper than a credit note and an argument.

The identity that posts usage must not be able to edit the price. Counting and pricing are different duties. A service account that can do both will be used to do both, on a Friday, by someone who wants the run to finish. Split them. The meter posts a count. A person, or a rule already stored on the contract, applies the rate.

Do not migrate historical usage by backfilling quantities for months the customer was never billed this way. History is a commercial question. If the old invoices used a different unit, loading the new unit under the old months rewrites the past. Leave history in the system that issued the invoice, and start the mapping on a date you name.

#Versus native features

Revenue Cloud and the products you already sell understand quantity, price, and a customer. A sales user can put a quantity on a line. That quantity means how many of that product. It does not mean "whatever the meter last said" until you have written the sentence that joins them. Native quoting is precise because the product was chosen by a person.

m3ter, on this record, counts and rates usage, and the aim is Agentforce Revenue Management. The count can feed a quantity only after the mapping exists. Native quantity does not become wrong because a meter exists. A meter does not become a product because Revenue Cloud has a quantity field. They meet at the mapping, or they do not meet.

This page does not rank metering against a price book you type by hand. Some products are sold as a fixed quantity, and a meter would only confuse the invoice. Some products are sold as usage, and a hand-typed quantity will drift from what the customer consumed. Choose by the contract you already signed, not by the fact of an acquisition. No order is implied by the table.

A row without a written mapping stays out of the invoice run. Adding it "so the migration is complete" completes the wrong thing.

#Alternatives, with no order

There is no AppExchange listing on this page. Inventing one would pretend a directory entry the close notice does not provide. The alternatives are commercial and operational choices. They are not ranked.

Keep billing the usage in the system that already issues the invoice, and do not copy counts into Salesforce yet. That option fits when the invoices are correct and the CRM is not the ledger. Salesforce can still hold the account and the contract. It does not have to hold the meter on day one.

Map one meter to one product, using a rate that already appears in a contract, and post counts with an identity that cannot edit price. That option fits when you have decided Salesforce should rate this usage, and you can point at schedule B. It is a small migration. It is not a price invention.

Keep a fixed quantity on the product and review it on a schedule a person owns. That option fits when the contract is not actually usage-based, and the acquisition tempted you to meter something the customer did not agree to buy that way. Do not add a meter to make the new tool feel used.

Wait until the mapping is a page someone in finance has signed. Waiting is a decision. The whiteboard number is the thing you are waiting to avoid.

A partner who ranks these, or who offers a default price per call so the project can start, is selling a rate you did not ask them to set. Send the rate back. Ask for the mapping. This page will not choose a winner among the options, because the contract chooses, and the contract is yours.

#What the walkthrough contains

The walkthrough is a series of stops.

Name the meter. What it counts, in one unit, for one customer identity you can match to an account. If the unit is ambiguous, stop.

Name the product. The Salesforce product that will carry the quantity. If you cannot find it, create it as a product decision, not as a side effect of a data load.

Write the mapping. Meter, unit, product, and the date the mapping starts. History before that date is out of scope unless finance names it.

Write the rating sentence from the contract. Quote the schedule. If the schedule has no rate, do not type one. Do not migrate usage by inventing a price.

Split the duties. The identity that posts counts cannot change prices. The person who changes prices cannot silently rewrite counts.

Name five refusals. No matching account. Two meters claiming the same calls. A negative count you cannot explain. A rate missing from the contract. A request to backfill years that were billed another way.

There is no price per API call on this page, and no fee for the work. The close notice does not contain them. Your statement of work can price the mapping exercise after the meter is named. It cannot price a fictional rate.

#Where the other pages fit

The implementation page holds the meter, the unit, and the invoice owner: m3ter, usage pricing, and Agentforce Revenue Management. Go there when you are ready to write the mapping. Do not go there for a rate the announcement never published.

What happened, who owns m3ter, the date, the missing purchase price, and the missing end date are on what happened to m3ter. Stay there when the question is the acquisition. Leave it when the question is whether a quantity field may receive a count.

The integration page is the path from a count to a charge: integrating m3ter with Salesforce. Read it when someone asks for the connector. The connector still waits for the mapping.

If the only number in the room was written on a whiteboard, photograph it and then erase it from the plan. Put the contract schedule in its place, or put nothing. An empty rate is a status. A made-up rate is a bill you will have to undo. Finance can sign the mapping. The announcement cannot.