# Should you migrate from m3ter

m3ter meters and rates usage. A meter is not a Salesforce product quantity until the mapping is written. Do not invent a price.

**Published:** 2026-08-31
**Canonical:** https://synconai.com/should-i-migrate-from-m3ter
**Author:** SynconAI Architecture Team

## In short

Salesforce completed the m3ter acquisition on 1 July 2026. m3ter is metering and rating for usage-based pricing, aimed at Agentforce Revenue Management. A meter is not a Salesforce product quantity until the mapping is written. Do not migrate usage by inventing a price. This page publishes no price, ranking, AppExchange listing, or shutdown date.

## Sources

- **Salesforce Signs Definitive Agreement to Acquire m3ter** (retrieved 2026-07-01)
  https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-m3ter/
  > Salesforce completed its acquisition of m3ter on July 1, 2026.

## What to take away

- The close on 1 July 2026 covers metering and rating, aimed at Agentforce Revenue Management. It does not set your price.
- A meter is not a Salesforce product quantity until the mapping is written. Count and charge are different sentences.
- Do not migrate usage by inventing a price per API call, or any other rate the announcement does not contain.
- This page does not publish a price, a ranking, an AppExchange listing, or a shutdown date.

## The guide

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.

| Job | What this record says about m3ter | What native features already do | What you still write |
| --- | --- | --- | --- |
| Sell a fixed number of a product | Not a replacement for a price book | A person enters quantity and price | Nothing, if the contract is not usage-based |
| Count what a customer used | Metering, aimed at Agentforce Revenue Management | Quantity does not count itself | The meter, the unit, and the customer |
| Turn a count into money | Rating, under a rule you wrote | A price on a product is a price you stored | The rating sentence, from the contract, not from a whiteboard |

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](/m3ter-agentforce-revenue). 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](/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](/integrating-m3ter-with-salesforce). Read it when someone asks for the connector. The connector still waits for the mapping.

| Question | Where it belongs |
| --- | --- |
| Should we migrate? | This page. Not by inventing a price. Not before the mapping. |
| What is the software now? | Metering and rating, aimed at Agentforce Revenue Management. |
| Versus native? | Quantity is a product count until a mapping says otherwise. No winner. |
| Alternatives? | Keep the current invoice, map one meter, stay on a fixed quantity, or wait. |

:::warn
Do not migrate usage by inventing a price. A meter is not a Salesforce product quantity until the mapping is written. The close on 1 July 2026 does not set a rate per API call, or any other rate.
:::

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.

## Questions

### Should I migrate from m3ter to Salesforce?

Do not migrate usage by inventing a price. Salesforce completed the acquisition on 1 July 2026. m3ter meters and rates usage, aimed at Agentforce Revenue Management. Map a named meter to a named product, using a rate the contract already has, or leave the quantity empty.

### What is m3ter software now?

It is metering and rating for usage-based pricing, aimed at Agentforce Revenue Management. The close was 1 July 2026. Aimed at does not mean present in every org. A meter still needs a mapping before it is a product quantity.

### How does a meter compare with a native product quantity?

A product quantity is how many of a named product you are selling. A meter counts usage in a unit your engineers defined. They are the same number only after someone writes the mapping. This page does not rank one above the other, and it does not state a price per API call.

### Is there an m3ter alternative on AppExchange?

This page does not name an AppExchange listing or a rank. The alternatives are choices: keep invoicing where you invoice today, map one meter with a contractual rate, keep a fixed quantity, or wait until finance signs the mapping.

### What belongs in an m3ter migration walkthrough?

The meter, the unit, the product, the start date, the rating sentence copied from the contract, and an identity that can post counts but cannot edit prices. A step that types a rate so the invoice run succeeds is not a walkthrough. This page does not add a shutdown date.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Revenue Cloud (https://synconai.com/salesforce-revenue-cloud-advanced).