CRM CLEANUP & MIGRATION · CRM クリーンアップ・移行

Japanese CRM migrations need correct character encoding for kanji and katakana contact names, formal email re-consent sequences, and a Japanese-language data validation process before going live

A CRM migration in Japan has technical and regulatory requirements that do not appear in a standard international migration checklist. Japanese contact names written in kanji and katakana are corrupted with some regularity during CSV exports, character encoding conversions, and platform imports. Japan's APPI law requires that individuals be informed when their personal data is transferred to a new system. And the business card database that has never been entered into the CRM is a problem every Japanese organisation has and almost none of them solve before the migration. We run CRM cleanup and migration projects for Japanese businesses that address character encoding, APPI disclosure requirements, business card digitisation, and the specific deduplication challenge created by Rakuten's masked buyer email addresses.

This is for you if

This service is for Nepal-based businesses that have been running their sales process through a combination of WhatsApp Business, personal phones, and Google Sheets — and have now decided to move into a proper CRM.

Your contact list exists across multiple Google Sheets maintained by different team members, each with a different column structure

You have exported contacts from WhatsApp Business and now have a list of names and phone numbers with no additional context

You have never defined what fields, pipeline stages, or lead source categories your CRM should have

You want to set up HubSpot, GoHighLevel, or a similar platform but are not sure what data to import or how to structure it first

What's broken

Problems We Solve

Japanese character encoding corrupted during migration

CRM migrations from legacy systems to HubSpot, Salesforce, or Zoho frequently corrupt Japanese-language contact data. The corruption happens at one of several points: when exporting data from the source system as a CSV file, when opening that CSV file in Excel (which can default to a Latin character set), when importing the file into the destination CRM, or when the destination CRM's import tool uses a different character encoding than the source file. The result is garbled kanji and katakana characters in contact name, company name, and address fields. Correcting hundreds or thousands of corrupted contact records manually after a migration is time-consuming and error-prone. Some records cannot be corrected because the original source data is no longer available in a clean format. The correct approach is to validate character encoding at every step of the migration pipeline before the live migration is executed. We test the export, the transformation, and the import using a sample dataset with Japanese characters, verify the encoding is preserved correctly at each stage, and only proceed to the full migration once the test validates clean output.

No re-consent sequence in Japanese for migrated contacts

Japan's Act on the Protection of Personal Information (個人情報保護法, APPI) requires that when a business transfers personal data to a third party or changes the purpose of data use, the data subject must be notified. A CRM platform migration, particularly one that involves a change in data processor, is a data transfer that requires disclosure. Most Japanese CRM migrations proceed without a formal notification to contacts because the migration is treated as an internal technical project rather than a personal data transfer. The APPI obligation is either unknown to the project team or is noted and deferred indefinitely. The practical mitigation is a Japanese-language notification email sent to all contacts in the migrated database before the new CRM is used for marketing communication. For contacts whose data will be used for new marketing purposes in the new CRM, a re-consent step is required. We draft the Japanese-language notification and re-consent sequence, configure it in the new CRM's email tool, and help the team determine which contact segments require notification only and which require active re-consent.

Business card (名刺) data not digitised before migration

Japanese business practice relies heavily on the physical exchange of business cards (名刺, meishi) as the primary contact-establishment ritual. Many Japanese businesses have accumulated years of business cards that were never digitised and entered into the CRM. This contact data exists only in physical form, in drawers, binders, or business card holders on individual desks. A CRM migration that does not account for this data leaves a significant portion of the organisation's contact history outside the new system. When the old CRM is decommissioned, the business card contacts — who may include some of the most significant long-term client relationships — are effectively lost from the system of record. We include a business card digitisation step in CRM migration projects for Japanese businesses: assessing the volume of undigitised cards, recommending a digitisation approach (manual entry, scanning service, or a dedicated business card scanning app such as Sansan or Eight), and building the digitised records into the migration file so they arrive in the new CRM alongside the existing contact database.

Duplicate records from Rakuten and DTC CRM imports

Japanese brands selling both direct-to-consumer (through Shopify, WooCommerce, or a branded e-commerce site tracked in a CRM) and through Rakuten Ichiba or Yahoo Shopping face a deduplication problem that standard email-matching tools cannot solve. Rakuten masks buyer email addresses by default, assigning each buyer a platform-specific masked email that changes per order. The same customer who bought on Rakuten and also submitted a DTC enquiry form appears in the CRM as two separate records with no matching identifier. Standard deduplication tools that match on email address will not find these duplicates. A matching strategy based on phone number, shipping address, or name plus postcode is required. Even with a more sophisticated matching strategy, some Rakuten-DTC duplicate pairs will not be identifiable without manual review. We build multi-signal deduplication processes for Japanese brands with Rakuten data, matching on phone number, postal address, and name combination in addition to email, producing a duplicate candidate report for review, and recommending a merge approach that preserves the Rakuten order history alongside the DTC CRM record.

What we engineer

What We Do

CRM data structure definition

Before any import, we work with you to define what fields the CRM needs, what your pipeline stages should be named, and what lead source categories apply to your business. This becomes the schema that all imported data maps to.

Google Sheet audit and standardisation

We audit all existing Google Sheets, identify inconsistencies in column structure and data formatting, and produce a single cleaned master import file with consistent columns, standardised phone number formats, and clear handling of blanks.

Cross-sheet deduplication

We identify contacts that appear in more than one sheet, standardise the matching fields, and merge duplicate rows so that each contact appears once in the final import file.

WhatsApp export processing

We take your WhatsApp Business contact exports, merge them with the Google Sheet data, and flag contacts that need additional context before they can be actioned in the CRM.

CRM import and configuration

We import the cleaned file into your chosen platform — HubSpot, GoHighLevel, or an equivalent — with correct field mapping, pipeline stage setup, and lead source property configuration.

Post-import validation

After the import, we check for records that did not map correctly, contacts missing required fields, and any duplicates that were not caught before the import. We provide a validation report and fix any issues before handing the CRM over for active use.

What changes

What Changes

Before
After
Before Each team member has maintained their own format. One sheet has phone numbers in column B, another has them in column D. Some rows have email addresses, most do not. Company names are in some rows and absent from others. Lead source is recorded in a free-text notes column by one person and missing entirely from another person's sheet. Before any CRM import can proceed, this data needs to be standardised into consistent columns for name, email, phone number, company, and lead source. Without that standardisation, the CRM import wizard cannot map fields correctly, and the resulting contact records are incomplete from day one.
After A single cleaned contact list exists, deduplicated and standardised, ready for import
Before Three sheets with significant overlap is a common pattern. The sales team has "leads 2022," "leads 2023," and "WhatsApp contacts" as separate files. The same contact appears in all three, sometimes with a different phone number format (+977-98XXXXXXXX in one, 98XXXXXXXX in another, 977 98XXXXXXXX in a third). When all three sheets are imported without deduplication, the CRM starts with multiple records for the same person. Deduplication before the import is the first step. It requires standardising phone number formats so that matching logic can identify duplicates correctly, then merging or removing the redundant rows before the import file is finalised.
After The CRM is configured with fields, pipeline stages, and lead source categories that reflect how the business actually works
Before A contact exported from WhatsApp Business is a name and a phone number. There is no conversation history attached to the export, no record of what was discussed, no indication of where the lead is in the sales process, and no notes from the sales person. Importing a WhatsApp export directly into a CRM produces a contact database that has names and numbers but no sales intelligence. For each WhatsApp contact that matters, the context needs to be added manually or through a structured interview with the sales team before the import. Without that step, the contacts are in the CRM but the information needed to action them is not.
After Every imported contact has a consistent data structure so that filters, segments, and reports work from day one
Before The Google Sheet has names and contact details but no record of where each lead came from. Without that data, the first CRM reports cannot show which channels — Instagram, referral, website, trade fair — are producing the best leads. The business cannot make a channel allocation decision based on CRM data if the CRM was never given that information. Adding lead source data retroactively is partially possible through team recall, invoice records, and message history, but it requires a structured process. Where it cannot be recovered, a consistent "source unknown" classification needs to be applied so that future data is not contaminated by blanks that look like a separate category.
After The team has a defined process for adding new contacts so the CRM stays clean going forward
How it works

Process

  1. 01

    Discovery call (60 minutes)

    60 minutes

    We review your existing Google Sheets and WhatsApp exports, understand your sales process, and define the fields, pipeline stages, and lead source categories your CRM needs.

  2. 02

    Data audit

    We audit all source files for structural inconsistencies, blank fields, phone number format variations, and duplicate entries. We provide a written audit report with findings and a recommended approach.

  3. 03

    Data standardisation and deduplication

    We produce a single cleaned master import file with standardised columns, consistent phone number formats, merged duplicates, and retroactively recovered lead source data where possible.

  4. 04

    CRM configuration

    We configure your chosen CRM platform with the agreed field structure, pipeline stages, and lead source properties before the import runs.

  5. 05

    Import and validation

    We run the import, check for mapping errors and missed duplicates, and produce a post-import validation report. Any issues identified are fixed before the platform is handed over.

  6. 06

    Team handover

    We walk the team through the configured CRM, explain how to add new contacts correctly, and document the data entry standards so the clean database stays clean.

Common questions

FAQ

How do I preserve Japanese kanji and katakana character encoding during a CRM data migration?

The most reliable approach is to use UTF-8 encoding throughout the entire migration pipeline. When exporting data from the source CRM, specify UTF-8 as the file encoding. When transforming or cleaning the data in Excel, open the CSV file using the Data Import tool with UTF-8 specified rather than double-clicking the file (which uses the system default encoding and will corrupt Japanese characters on most Western-locale systems). When importing into the destination CRM, verify that the import tool accepts UTF-8 and that the import preview shows Japanese characters correctly before committing the import. Run a post-import validation query that checks a sample of Japanese-language fields in the destination system against the source file. If you are using a middleware tool such as Make or Zapier to move data, verify that the Japanese character fields are being passed as UTF-8 strings and are not being truncated or re-encoded at any step.

What Japanese APPI requirements apply when migrating customer data to a new CRM platform?

Under Japan's APPI, when a business changes the purpose for which it uses personal data, or transfers personal data to a third party (including a new data processor), it must notify data subjects or obtain consent depending on the nature of the change. A CRM platform migration that involves moving data from one software vendor's infrastructure to another is a transfer to a new third-party processor and requires notification to data subjects. The notification must identify the new purpose of use and the categories of third parties receiving the data. For marketing contacts, if the new CRM will be used to send different types of communication than were sent from the old system, a re-consent step is required rather than notification alone. The 2022 APPI amendments, which came into effect in April 2022, strengthened these requirements, including the introduction of opt-out registration requirements for certain categories of data sharing. Consult with a Japanese legal adviser for the specific obligations that apply to your migration scope.

How do I digitise Japanese business card contact data before a CRM migration?

The most scalable approach for large business card volumes (more than 500 cards) is to use a dedicated Japanese business card management service such as Sansan (enterprise) or Eight (SMB). Both services offer digitisation by human operators who read and transcribe Japanese characters accurately, which is more reliable than OCR for handwritten or non-standard card formats. The digitised data can then be exported as a CSV and mapped into the migration file. For smaller volumes, manual entry by a Japanese-speaking team member with a standardised entry template is sufficient. The key fields to capture are full name in kanji, full name in katakana (for pronunciation and sorting), company name in kanji, company name in katakana, job title, email address, phone number, and the date and context of the initial card exchange (which serves as the APPI collection record).

How do I deduplicate Rakuten buyer records with DTC CRM records when email addresses are masked?

Rakuten masks buyer email addresses using a format specific to each buyer-seller relationship, meaning the same buyer will have a different masked email address for each Rakuten store they purchase from. To deduplicate Rakuten records against DTC CRM records, you need a matching strategy that does not rely on email address. The most effective combination is: phone number (if collected at checkout), shipping address (full postal address string match), and name plus postal code. Build a matching script or use a deduplication tool that runs these three matching signals and scores each candidate pair by the number of signals that match. Pairs matching on two or three signals can be merged with high confidence. Pairs matching on one signal require manual review. Note that because Rakuten buyers may have different email addresses per store, the merged record should retain both the masked Rakuten email and the DTC email, with the DTC email set as the primary contact email for marketing purposes.

What is the best CRM for a Japanese SMB migrating away from a legacy domestic CRM system?

For Japanese SMBs migrating away from a domestic CRM such as eセールスマネージャー or a legacy kintone configuration, the most common migration targets are HubSpot (for businesses prioritising marketing automation and inbound), Zoho CRM (for businesses prioritising cost-effectiveness and a full suite including Zoho Analytics), and Salesforce (for businesses with complex enterprise requirements or that need to integrate with enterprise partners already on Salesforce). HubSpot has strengthened its Japanese-language interface and Japanese-market support since 2021 and is the most commonly recommended option for Japanese SMBs that need a balance of capability and usability. kintone by Cybozu remains a strong option for businesses whose processes are highly customised and who need a database-plus-workflow tool rather than a purpose-built CRM.

Our team

The people behind the work

Not a black box. Real specialists you can call, with their names on the work.

Niraj Raut

Niraj Raut

Founder — Ecommerce SEO
Keshab Joshi

Keshab Joshi

PPC Expert
Hawrry Bhattarai

Hawrry Bhattarai

Google Ads Expert
Arogya Rijal

Arogya Rijal

SaaS SEO Expert
Start here

CRM cleanup and first-time CRM setup for Nepal businesses

If your contact data is currently split across Google Sheets and WhatsApp exports, the right starting point is a data audit, not a CRM purchase. The audit identifies what you have, what state it is in, and what work is needed before a CRM import will produce a usable database.

Ignited Nepal is a Growth Engineering Company based in Kathmandu. We work with Nepal businesses setting up their first CRM and with teams that need their existing data cleaned before it can be used.