Two questions quietly derail a lot of CRM migrations. First: what do you do with years of deals recorded in a currency your business no longer uses? Second: what happens to records written in another language, or in a different alphabet, when the team wants everything readable in one language? Neither is hard to solve, but both need a decision before the first record moves. This guide walks through the options and the trade-offs.
When migrating a CRM with legacy currencies or multilingual data, keep each historical deal in its original currency and amount, record the exchange rate that applied, and let the new CRM report in your company currency. For text in other languages, keep the original, add a translated field only where people need it, and test that names and characters survive the load intact. Decide these rules in the mapping phase, test them on a subset, and document them. Vantage Point handles these decisions as part of its data migration services.
Businesses change currencies for many reasons. A country adopts a new currency. A company moves its headquarters, is acquired, or starts reporting in a parent company's currency. Whatever the cause, the old CRM ends up holding deals in a currency nobody uses anymore, side by side with newer deals in the current one.
If you migrate those amounts as plain numbers with no currency attached, your reports will add old and new amounts together as if they were the same unit. Pipeline totals, win rates by value and customer lifetime value all become wrong, often without anyone noticing.
There are three common approaches. The right choice depends on how you report and what your finance team needs.
| Approach | How it works | Best when | Watch out for |
|---|---|---|---|
| Keep original currency | Each deal keeps its original amount and currency code. The CRM converts to company currency for reports. | You need accurate history and audit-friendly records. | The legacy currency must be set up in the new CRM with a sensible exchange rate. |
| Convert before loading | Old amounts are converted to the current currency in the source file. | History is only used for rough trends. | The original value is lost unless you store it in a separate field. |
| Hybrid | Load converted amounts, plus custom fields holding the original amount, original currency and rate used. | You want simple reporting and a clear record of the original. | More fields to maintain, and users must know which field to trust. |
For most teams, keeping the original currency is the safest default. It preserves the truth of each deal and lets the platform do the conversion consistently.
Both platforms support multiple currencies on paid editions, with some important differences in how conversion works.
HubSpot: you set a company currency and add others with exchange rates. Each deal has a currency property, and HubSpot calculates an "amount in company currency" for reporting. According to HubSpot's documentation, open deals use the latest exchange rate, while closed deals with a close date use the rate that was in effect on that date. That makes accurate close dates important during migration, because they decide which rate applies. HubSpot also keeps a currency history you can review.
Salesforce: multi-currency must be enabled, and each record carries a currency code. With advanced currency management, you can maintain dated exchange rates so opportunities convert using the rate for their close date. Dated rates apply to opportunities and some related objects, not every object, so check which fields your reports rely on.
In both platforms, load your historical exchange rates before you load historical deals. Otherwise the system may apply today's rate to deals that closed years ago.
Records written in more than one language create three separate problems:
The instinct is often to translate everything into one language during the migration. That can work for a handful of fields, but it has real costs. Machine translation can get names, addresses and legal entity names wrong, and once the original is overwritten, you can't check it.
Treat translation as an addition, not a replacement. A practical approach:
If you also run marketing in several languages, our guide to multi-language setup in HubSpot covers website and email considerations.
Most character problems come from files, not from the CRM. A spreadsheet saved in the wrong format can silently replace letters with question marks or odd symbols. To avoid it:
Scripted loads through an API usually handle encoding more predictably than manual spreadsheet imports, which is one more reason to use them for large or complex migrations.
Write a one-page standard before the load, so everyone applies the same rules. It should cover:
This document also helps new team members understand why some records look different from others.
Build your subset migration around the edge cases, not just typical records. Include deals in every currency, deals that closed around a currency change, records in each language and alphabet, and a few with missing or odd values. Then check:
Only move to the full load once business users have signed off on these checks. Our guide to filtering data before the full load covers the rest of the pre-load checklist.
Vantage Point plans and executes CRM migrations with the data rules agreed up front, including currency history, multilingual records and character handling. Our system integration and data migration team builds the mapping, runs subset tests and reconciles every load, and our CRM and marketing automation services set up HubSpot or Salesforce so reporting works from day one. We've completed 400+ engagements for 150+ clients, with a 4.71/5.0 average engagement rating and 95% client retention. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Decisions about currency history and translated records are easiest to make before the first load. Vantage Point can assess your data, recommend the right approach, and test it on a subset your team approves. Talk to Vantage Point about your CRM migration.
Usually not. Keeping each deal's original amount and currency preserves an accurate record, and the CRM can convert to your company currency for reports. If you do convert, store the original amount, currency and rate in separate fields.
Yes, on Starter, Professional and Enterprise subscriptions, with different limits on how many currencies you can add. Each deal has a currency, and HubSpot calculates an amount in company currency for reporting using the exchange rates you set.
According to HubSpot's documentation, closed deals with a close date use the exchange rate in effect on that date, while open deals use the latest rate. Accurate close dates therefore matter during migration.
Yes. With multi-currency and advanced currency management enabled, Salesforce can store dated exchange rates so opportunities convert using the rate for their close date. Dated rates don't apply to every object, so check your key reports.
Translate selectively. Keep names and legal entity names in their original form, add translated or romanized versions in separate fields where needed, and focus translation effort on active customers and open deals.
Usually because the import file wasn't saved in UTF-8 encoding. Save and check files as UTF-8, test every alphabet in a subset load, and compare sample names between the source and the new CRM.
Finance should approve currency handling, and sales or service leaders should approve language and picklist rules. Document both in a short data-handling standard before the full load.