When a SaaS buyer asks on X, “Can we migrate our data?”, do not answer with an unqualified yes. Ask which system they use and what must survive the move. Confirm the parts covered by your current import documentation, then assign someone to review a representative export for anything unverified. The useful answer is a scoped path forward, not a promise that every record and conversation will transfer.
Find out what “our data” means to this buyer
A buyer may mean customer records, years of support conversations, or both. Those are different transfer requirements. Start with the fields below; if the public post lacks the details, ask a short question rather than requesting an export in the thread. Distinguish what is essential for a purchase decision from data the buyer would merely like to retain.
Also ask what a successful result would look like. “Keep our customers” might mean creating customer records, preserving their custom fields, or keeping each customer linked to their past conversations. Knowing which outcome is indispensable prevents a record-only import from being mistaken for a complete migration.
- Source system: Which product holds the data now, and is more than one workspace or account involved?
- Export: What formats can the buyer obtain for the relevant data? If they do not know, ask them to check before you assess a file-based import.
- Essential records: Which record types must arrive, and must existing records be updated or only new ones created?
- History and relationships: Must old conversations, notes, dates, attachments or links between records survive? Which of those are deal-breakers?
- Custom fields: Which buyer-defined fields and values must remain usable in the destination?
Match each requirement to a documented import path
Check your own current import documentation against the buyer’s required data types and available export. Look for supported destination records, accepted file formats, required identifiers, field mapping and relationships. Do not treat “CSV import available” as proof that every column, attachment or historical event will move. For example, HubSpot describes spreadsheet uploads that map columns to properties to create or update records and define relationships; its documentation also identifies supported activities and conditions for some association features. That illustrates why the specific data and import conditions matter, not what your product can import.
Make the decision per required data type. If your documentation covers it and the buyer’s source can supply the needed format, describe that documented path and its conditions. If the format, fields or history have not been checked, mark that portion for sample review. If you know a mandatory item cannot be moved by any path you actually offer, say so rather than suggesting a record import solves the buyer’s requirement. An undocumented path is unconfirmed, not automatically impossible.
Worked decision: records are documented, history is not
Consider this fictional exchange. A buyer posts, “Can we move our customer records and old support conversations from our current tool?” The fictional seller’s current documentation covers customer-record CSV imports, including mapped standard fields. It says nothing about importing support conversations. The buyer has not named the current tool, confirmed that it exports CSV customer records, or specified which fields and history are essential.
The resulting decision is to identify the documented customer-record path without claiming it works for this buyer’s export yet. Conversation history needs a separate check; even if records can be imported, the seller cannot infer that old threads or their links to customers will follow. Ask for the source system, export formats and required fields first. If the buyer can provide a representative sample through an appropriate private channel, the seller’s migration specialist can compare it with the available import options and report which parts are supported, need transformation or remain unverified.
If conversations are mandatory and the sample review finds no workable transfer path, the answer is not “we can migrate you” merely because customer records can move. Tell the buyer the narrower supported scope and let them decide whether that meets their requirement. If they only need active customer records, the record path may be enough—but verify their export and required fields before confirming the transfer.
Give a scoped public reply and a named next step
For the fictional seller, a public reply could say: “We have a documented CSV import path for customer records, but I’d need to check your current tool’s export and required fields before confirming it fits. I can’t confirm that old support conversations transfer from the information here. Which tool are you leaving, and is keeping that history essential? If you’d like, our migration specialist can review a representative export privately and tell you what we can support.” Use this wording only if the documented path and specialist are real for your company; otherwise name the actual person or team who can perform the check.
Keep the export itself out of the public thread. Tell the buyer how your team will arrange an appropriate private handoff, then have the person responsible compare the sample with the destination’s documented import requirements. The follow-up should separate confirmed scope from items that need preparation or cannot yet be confirmed. It should not quietly expand a verified record import into a promise about all historical data.
ReachFast says it finds public X requests and prepares a suggested reply that opens typed in the X thread; you decide whether to send it. If a migration question appears on your board, review the live post and replace any unsupported transfer claim in the draft before replying. ReachFast can help start the conversation, but your documentation and the assigned reviewer determine the migration answer. If the buyer is instead asking whether a particular integration or version is supported, use the separate compatibility guide.
