Migrate from HubSpot

Scope first: is HubSpot still the CRM?

The first question is not which platform to use, it is what you are replacing. HubSpot is a suite: a CRM that holds companies, contacts, deals and tickets, a marketing product and a sales product. LoopNow is an execution runtime for campaigns, WhatsApp, voice and workflow, and it connects to a CRM rather than trying to be one. If the sales team lives inside HubSpot pipelines, replacing it is a different project with a different sponsor, and bundling it with a marketing migration is how both fail.

Three scopes are possible and only one of them is usually correct. Full replacement moves the CRM too, which means deals, notes, ticket history, sequences and custom objects, and it needs a sales operations owner who is not the marketing team. Execution-only keeps HubSpot and moves campaigns, WhatsApp, voice and consent recording. Staying put is legitimate if the seams between channels are not actually costing you anything. Most mid-market Indian teams should take the middle option and be explicit that they did.

Whichever you choose, write the scope on one page with a list of what is out of scope. That page is what stops a request on day six to also migrate the quote objects because somebody in sales assumed it was included. It also frames the success criteria: for an execution-only migration, success is that the first campaign, the first WhatsApp template and the first voice call all write back to the same contact record inside HubSpot.

What moves when the CRM stays

With HubSpot retained, the migration list becomes short and specific. Marketing contacts and their consent state. The templates for the emails that go out every month. The automations that touch marketing, not the sales sequences. The sending domain and its DNS records. The form intake points, eventually. And a baseline of campaign performance so you can tell whether the new sender is doing better or worse than the old one.

Everything else stays. Deals, pipelines, quotes, tickets, meeting links, call recordings, notes, tasks and custom objects are HubSpot’s job and should remain there. That is not a limitation, it is the reason the project is tractable. A marketing runtime that tries to also be the CRM creates the exact duplication this scope is designed to avoid, and the duplication always shows up as a contact record with two owners and one stale email address.

The one piece people forget is the unsubscribe and consent record. If HubSpot holds consent today, the new platform needs a synchronised view before the first send, not after. Export the consent fields, map them into the ledger with their timestamps and sources, and decide which system is authoritative when they disagree. Deciding that after a complaint is too late, and it is a decision that takes ten minutes on day one.

Two channel-specific items sit outside the CRM sync and are worth naming on day zero. If HubSpot was also your WhatsApp sender, the templates have to be rebuilt and resubmitted to Meta, because approval belongs to the account rather than to your business, and the category decides both the review outcome and the price. If it was also your SMS sender, commercial SMS in India needs a DLT-registered header and registered templates under your entity, which is a queue of its own with no relationship to either platform. Both cost days of calendar time rather than hours of work, and both should be started before the data move.

Syncing contacts without building a second CRM

A sync is not an import that runs on a schedule. It is a set of rules about which system wins for which field. Pick a stable key that survives an email address change, ideally the CRM record identifier rather than the email, and store it on the marketing side. Then decide, field by field, whether the CRM is authoritative, the marketing platform is authoritative, or the most recent write wins. Marketing usually owns engagement fields such as last clicked; the CRM owns identity and ownership.

Deletions and merges are where syncs break. If two contact records are merged in the CRM, the marketing side must collapse them without sending a duplicate message to the surviving record. If a record is deleted or erased, the marketing side must suppress rather than delete silently, so the next import cannot resurrect the person. Test both cases deliberately with two test records before cutover, because neither is easy to simulate after the fact.

Write-back is the part that makes the whole arrangement worth it. When a WhatsApp conversation ends, the outcome should appear on the timeline of the contact in HubSpot, not in a separate tool that only the marketing team opens. That is the difference between a migration that improves the business and one that adds another tab. If the write-back is not working, the migration is not finished, regardless of what the campaign dashboard says.

Lifecycle stage, consent and the record of truth

Lifecycle stage is a CRM concept and should stay one. A marketing platform can read it, segment on it, and use it as a workflow condition, but it should not invent its own version, because two definitions of qualified produce two reports and one argument. Sync the stage as a read-only field, and if marketing activity should move it, make that an explicit write-back rule the sales team has agreed to rather than a side effect nobody documented.

Consent is the opposite case. It deserves its own record in the execution layer, because consent is channel-specific and time-stamped, and a CRM property is a poor place to keep a history. A person can consent to WhatsApp order updates and withdraw consent for marketing email on the same day. A single opt-out checkbox cannot express that, and under the DPDP framework you are expected to be able to show what was agreed, when, and on the basis of which notice.

The commercial argument is simpler than the legal one. Marketing contacts are the ones who are subscribed, unmuted and have been mailed in the last twelve months; unsubscribed and suppressed contacts are free and unlimited on LoopNow. A clean consent model therefore reduces the bill as well as the risk. Importing every record in the CRM as a marketing contact, including the ones who never opted in, is how a migration doubles its own cost on day one.

Marketing emails and the tracking parameters people forget

Rebuilding a marketing email is mostly a copy and layout exercise, and it is the part teams budget for. The part they do not budget for is the machinery around the email: the unsubscribe link, the preference centre, the view-in-browser link, the UTM parameters on every call to action, and the branded click-tracking domain if one is in use. Each of those is invisible in a preview and each of them can quietly break a report or a compliance obligation.

Build a checklist and walk every template through it. Does the unsubscribe link work without a login, and does it reach the right preference page. Do the UTMs follow one convention, in lower case, with a consistent source and medium. Is the click-tracking domain published and validated, because a broken one makes every link in the email fail at once. Is there a plain-text alternative. Does the footer carry the sender’s legal identity and address.

Then verify with a real click rather than a preview. Send to a seed address, click the first button, and follow the visit into analytics. If the source shows as direct, the parameters are being stripped somewhere between the email and the landing page, usually by a redirect. That is a twenty-minute fix now and a quarter of misattributed revenue later, and it is the single check most migrations skip.

Automation: what a workflow can and cannot stand in for

HubSpot automations are usually built around contact properties: when this field changes, wait, branch, send. A runtime workflow is built around an outcome: a trigger arrives, context is retrieved, a decision is made, tools are called, an outcome is written back. For marketing automations the two models overlap enough that a rebuild is straightforward. For sales sequences they do not overlap at all, and sales sequences should stay in the CRM where the sales team can see and edit them.

The honest rule is that anything a salesperson owns stays with the salesperson’s tool. Nurture, onboarding, re-engagement and renewal reminders are marketing and belong in the runtime. One-to-one sequences, meeting follow-ups and deal-stage nudges are sales and belong in HubSpot. Moving them creates a situation where a rep pauses a sequence in one system and it keeps sending from the other, which is exactly the kind of failure that ends trust in a new platform.

For the automations you do move, rebuild with an explicit exit condition and test it. Most old automations acquired an exit rule after an incident: stop if they reply, stop if they buy, stop if they complain. If the rebuild reproduces the happy path and forgets the exits, the first cohort gets three messages after converting. Test the exit before you test the send, because the exit is what protects the customer relationship.

Forms, landing pages and the gap between them

A form is not a page element, it is the front door of your consent record. When you replace a HubSpot form you are replacing the place where the wording is shown, the checkbox is ticked, the source is captured and the record is created. Miss any of those and the migration has quietly weakened your evidence. That is why the forms move last, after campaigns are stable and after the CRM sync is proven, and why they move one at a time rather than all at once on a Friday.

Inventory every intake point before you rebuild any of them. The contact page form is obvious; the chat widget, the pricing enquiry, the webinar registration, the exit-intent popup and the QR code on a print brochure are not. Each has a downstream destination: a workflow, a notification, a list, a sales assignment rule. Write the destination next to each intake point, then decide whether the new form reproduces it or whether that destination should be retired along with the form.

Keep the old forms live until the replacements have passed a real submission test, including the thank-you path and the notification email. Submissions that vanish are worse than submissions that arrive twice, because nobody notices a silence. Compare submission counts for a week after each move; a drop that coincides with the switch is a bug, not a market signal. Preserve the source values in hidden fields so attribution survives the change of front door.

The second DKIM on a domain that already sends

If HubSpot already sends marketing mail from your domain, the DNS records for that domain are already in use and already trusted. Adding a second sender means either sharing the existing records or splitting the stream onto a subdomain. Sharing is faster and riskier, because the SPF record accumulates includes until it exceeds the lookup limit, and the failure mode is a permerror that affects every sender at once. Splitting is slower and safer, and it gives marketing its own reputation to lose.

Whichever route you take, publish the new DKIM selector and verify it before you touch SPF. A DKIM key that is published but not signing produces mail that looks authenticated in a dashboard and fails at the receiver. Then add the new sender to SPF, keeping the old include in place for the overlap, and move DMARC to a monitoring policy with a reporting address you actually read. Do not jump to a rejecting policy on cutover week, because you will reject your own transactional mail before you find out why.

Leave the old DKIM record published for a month. Mail in flight, forwarded copies and providers with cached DNS still validate against it, and removing it is how a technically correct migration produces a week of authentication failures. Keep a plain text note of every record you changed, with the old values, in a file the team can find. The person who will need it at eleven at night is not the person who made the change.

Two bills, two currencies, one quarter

For one quarter you will pay for both systems, and that is the correct outcome rather than a failure of planning. HubSpot contracts are often annual, so the marketing seats keep billing whether or not you send from them, and the earliest realistic saving is at renewal. Budget the overlap openly, tell finance the date the saving starts, and resist the urge to cancel a seat mid-quarter to prove the project paid for itself. Losing the read-only archive to save one month is a bad trade.

The billing shape also changes. HubSpot billing is typically card-based in dollars or rupees depending on the contract, while LoopNow prices in rupees and adds eighteen percent GST with a GSTIN invoice on every payment, payable by UPI, netbanking, card or NEFT for annual plans. If you are GST-registered, that invoice is input credit rather than cost, which narrows the real gap between the two quotes. If you are not, the tax is simply part of the price and should be in the comparison. The subscription also carries a residency difference worth stating plainly: LoopNow stores data on AWS Mumbai, ap-south-1, while the CRM you are keeping is not an Indian-region product, so the split should be documented rather than assumed.

Watch the allowance rather than the plan name. Overage on email is three paise per delivered message and the spend cap is on by default, so a peak festive week is bounded but not free. The mistake to avoid is choosing a tier from a quiet month and then paying overage for eleven months. Look at your largest sending week in the last year, add the growth you expect, and choose against that number rather than against the average.

Cutover with HubSpot still live

Because the CRM stays, cutover is narrower than in a full replacement and the failure modes are different. You are not risking the pipeline, you are risking the connection between the pipeline and the channel. The sequence is: freeze scheduled campaigns, confirm the consent sync is current, send the seed test to Gmail, Outlook and Rediff, publish the DNS change, swap the API keys in any system that calls the old sender, then unfreeze one segment and watch the write-back in the CRM.

Do the first send to a small segment and check three things afterwards. Did the message arrive, did the click register with the right parameters, and did the contact record in HubSpot show the activity. All three matter and they fail independently. A campaign that arrives but never appears on the timeline means the write-back is broken, and the sales team will not trust the new platform until it is fixed. Fix it before scaling volume, not after.

Keep the old marketing path warm for a week rather than a day, because marketing calendars are less forgiving than transactional traffic. If a webinar reminder has to go out on day three and the new template is not ready, send it from the old platform and note why. A migration that insists on purity at the cost of a missed commitment teaches the team to route around the new tool, which is a much harder problem to undo than a delayed template.

Where HubSpot remains the better tool

There are things HubSpot does that a marketing runtime should not try to replace, and saying so is part of an honest guide. If you want one vendor for CRM, marketing, sales and service, with a large partner ecosystem and enterprise governance around it, HubSpot is the coherent answer and unbundling it creates work rather than removing it. The same is true if your reporting depends on cross-object joins between deals, tickets and campaigns, or if your team is already expert in the tool and the switching cost is real.

The case for moving the execution layer is narrower than a feature comparison suggests. It is about channels HubSpot treats as add-ons, a consent ledger that records channel-specific permission with timestamps, rupee billing with GST invoices and UPI, and data held in an Indian region. Those are procurement and operations arguments rather than product arguments, and they are the ones that actually decide these projects in Indian mid-market companies.

A useful test is to write down the three things that would have to be true for you to move back in a year. If the list is about price, you are buying on price and should expect to re-evaluate annually. If it is about a capability, name the capability and check whether the runtime really covers it. If the list is empty, you are migrating for reasons nobody can articulate, and the cheapest option is to fix the seams between your current tools instead.