Less Annoying CRM to Attio: a migration case study

I moved an investment firm's records from Less Annoying CRM to Attio and rebuilt how it tracks relationships and investments. Tags became separate fields, investment amounts became records that could be added up, and saved views made missing follow-ups and inconsistent pipeline entries easier to find.

The migration is complete. The team still needs to finish moving over and reconcile changes made in the old CRM since the import. This is an account of the work built and checked so far.

Why move from Less Annoying CRM to Attio?

The firm relied on one person to turn CRM records into answers. When a partner wanted to know which relationships were overdue for contact, that person exported the contacts and worked through a spreadsheet. Questions that should have been answerable during a meeting became work for somebody afterwards.

The team had kept years of relationship history in Less Annoying CRM. They had also built their own system of tags to organise it. By the time I joined, getting a useful list meant cross-checking those tags by hand.

I built the Attio workspace around the questions they needed to answer: who needs a call, what money is committed, and which companies have been sitting in the pipeline without a decision.

What happened to the tags?

I separated the tags by what they meant. A person's relationship to the firm, their capacity tier, mailing subscriptions and event attendance became distinct fields. That made it possible to combine those details in a saved view without having to work out the meaning of each tag again.

For example, a partner can narrow a prospect list by fund interest and relationship tier, then check who is due for contact. The team had already decided which distinctions mattered. My job was to give those distinctions a place in the data.

I kept their pipeline stage names too. They had enough to learn with a new CRM.

How were the investment records rebuilt?

The old setup stored investment dates and amounts in numbered text fields on each person's record. I replaced those fields with a separate record for each cheque, linked to the investor where the holder could be matched. Amounts became currency values that the CRM could total.

For the funds with supplied spreadsheets, I rebuilt the records from those files and checked the imported values against them. Each record has its fund, date and amount, with the source details retained for checking. An investor's page shows the linked investments alongside their total.

There are gaps. Some holder names still need the firm's help to match them to a person. One fund's source file wasn't supplied, so its records still come from the old CRM's text fields. Those records are identified separately. I left uncertain links blank.

What can the new views show?

The saved views bring together information the team previously had to assemble. One shows relationships due for contact. Another shows committed amounts alongside pipeline stages, which makes it easier to spot an amount that disagrees with the stage on the same record.

The overdue-contact view needed a careful definition. In the source history, a mailed flyer had been logged as a note on each recipient, just as a personal call could be. Using the latest note would have made those people look recently contacted.

I excluded mass mailings from the personal-contact calculation and compared the remaining history with the firm's own contact schedule. It still depends on what was logged. An unrecorded conversation won't appear in that calculation.

The deal-flow views also expose companies that have been in cultivation for a long time. The team can review them and decide whether to follow up or close them. The view makes the question visible; it doesn't make the decision.

What could the migration not recover?

The source data available for this migration had each deal's current stage and pipeline entry date, but no usable history of stage changes. I could show how long a company had been in the pipeline. I couldn't reconstruct how much of that time it had spent in diligence.

Recording each stage change would make that measurement possible going forward. That is follow-on work, and it would only start collecting history from the day it runs.

Source identifiers help with checking too. Imported records retain their Less Annoying CRM identifiers so they can be traced back. That provides a way to investigate a discrepancy; it doesn't establish that every attachment or email is present in Attio.

Who owns the fields once automation is involved?

The workspace design separates fields the system fills from fields the team edits. System-owned fields are labelled, and a person shouldn't type into them because the next run can replace that value.

The rule for future automation is to leave the team's fields alone. If a system thinks a team-entered value needs changing, it should write a suggestion for someone to review. I want a partner to be able to correct a record without wondering whether a background job will undo it.

What still needs to happen before the team switches?

The records and saved views are in Attio, and I've delivered the CRM guide and a walkthrough of exporting data. The remaining changeover includes moving everyone onto the new setup and reconciling anything changed in Less Annoying CRM since the migration. The team demo is still ahead.

I don't yet have a measured reduction in reporting time or results from the team's day-to-day use. The work so far has made the records easier to query and the unresolved data easier to see. The rollout will show how well that fits the way the team works.

Questions about a similar migration

Can I import Less Annoying CRM data into Attio with a CSV?

Less Annoying CRM supports exports of filtered contacts and pipelines, and Attio supports CSV imports. For this project, I used migration scripts to restructure the data and keep source records traceable. Before choosing an import method, decide where each field and relationship should go and how you'll check it afterwards.

Will all the old CRM history appear in Attio?

Check each kind of history separately. This migration brought over non-empty notes and open tasks, with source identifiers for tracing records back. Email history, attachments and stage changes have different limits. A successful contact import doesn't tell you whether those are covered, so I wouldn't promise a complete history based on that alone.

Can the team keep using the old CRM during the move?

This team has continued using Less Annoying CRM while preparing to switch. That means changes made after the import need a final reconciliation. Agree when people will stop updating the old system and who will check the changes before treating the new CRM as the place everyone works.

What does a project like this cost?

My current project pricing sets out the starting range and how further phases are agreed. A migration, team rollout and ongoing automation can involve separate pieces of work. The starting price for a new project isn't a total quote for everything described here.