How to Adopt New Software Without the Pain
New software means retraining, lost records and lock-in worries. How restoration and carbon teams keep what works, run both and switch in the off-season.
A carbon developer's CIO asked me recently what switching to us would look like. The question usually comes with three worries. Will our field team lose a season learning a new app? Will years of records get lost on the way? Will we be stuck with whoever we pick?
New tools promise a lot. Adopting them is where it hurts. The switches I've seen go well were never one big jump. They were a series of small, reversible steps, where the old tools kept working until the new one had earned its place. This checklist works whichever software you're adopting.
Disclosure: we make software for restoration and carbon projects, and this is also how we bring teams onto it. The steps apply to any tool, ours included.
The checklist
- Take stock of what you have: spreadsheets, survey forms, map files, photos and paper.
- Name one lead who knows the operation and can make decisions.
- Test an export before you sign anything.
- Check how the new tool handles what makes your project different.
- Bring your history as it is, and flag doubtful records instead of dropping them.
- Run the old and new tools side by side until they agree.
- Keep the field tools that work.
- Switch the field team in the off-season, through a trained lead.
Take stock of what you have
Before you talk to any vendor, list where your records live today. Most organizations find more than they expected: a planting sheet per season, a nursery sheet nobody else opens, survey forms with years of submissions, boundary files on someone's laptop, and a folder of photos with no names.
| What | Where it usually lives | What to write down |
|---|---|---|
| Spreadsheets |  Excel files,  Google Sheets,  Airtable bases | Who keeps each one, which copy is current, which seasons it covers |
| Survey forms |  KoboToolbox,  ODK,  Survey123 | Each form's versions, and how submissions link to sites or farmers |
| Map files | Shapefiles, KML, GeoJSON,  QGIS projects | Which boundaries are current, and the ID that ties each one to its site |
| Photos | Phones,  Google Drive, form attachments | Whether each photo can be tied to a site, plot or visit |
| Paper | Field sheets, notebooks | What was never typed up, and who holds it |
The last column matters most. The hard part of switching isn't copying rows. It's knowing which record belongs to which site, farmer or plot. If that link only lives in someone's head, write it down now. Our guide to where restoration records live helps you place each one.
Name one lead
Switching needs one person on your side who knows how the operation really works, is comfortable with spreadsheets, and can decide without calling a meeting. Not a committee, and not only IT.
The vendor should do the heavy lifting: bringing records in, matching columns to fields, building forms. Your lead answers what only your team can answer. Is this the same village spelled two ways? Which of these two boundaries is current? Does this column still matter? If the lead is also the person who will train the field team later, even better.
If that person is already stretched thin, say so early. It's a bottleneck I see often, and it's easier to plan around at the start than halfway through.
Test an export before you sign
Worrying about lock-in is reasonable. A test tells you more than a contract clause. Before you sign with anyone, us included, ask them to bring in a sample of your real records and then export them back out.
Check four things in what comes back:
Records. Every row you sent is there, with its fields.
Boundaries. Sites and plots come out as spatial files you can open in QGIS or Google Earth.
Links. IDs still tie each record to its site, plot or farmer.
Photos. Attachments come out too, not just the rows.
If getting your records out takes a support ticket, you know what leaving will feel like. Put the export in the contract as well, but test it first. And share nothing until the vendor has signed an NDA.
Check how it handles what makes you different
Every project is different. Your methodology has its own monitoring rules, your partners report in their own formats, and somewhere in your flow there's a step nobody else does quite the same way. However complete a platform is, no platform handles all of that well on day one.
So ask two things of any tool you consider. Does it cover the common work out of the box: records, maps, field capture and reports? And when your flow needs something specific, can it be built inside the same system, rather than patched on the side in another tool or spreadsheet?
That's what we built Restoration Scope for. It comes complete, with the field app, records, maps and donor portals ready to use. When your project needs something only it does, we build it on top: custom code, processes or geospatial analysis, in the same system as everything else.
Bring your history as it is
You don't need to finish cleaning up before you switch. Send the files as they are and keep the originals untouched, as an archive you can always go back to. When you do correct something, write down what changed and why.
Your history is often why you want new software at all. Past seasons are your baseline: what was planted where, what survived, what a funder was told. When Acción Andina brought its partners' planting records into one system, the older seasons came along, linked to the sites they belonged to.
Messy records are normal. A farmer list might spell one village several ways, or list the same farmer under two villages. The tempting move is to guess: merge the look-alikes, pick one of the two villages, drop what doesn't fit. Every guess quietly changes your records. Flag them instead, and let your lead decide each one.
Then check what matters most before anything else: how many trees, which species, where and when, and whether later monitoring links back to them. If those match the old tools, the rest can be checked over time. Four basic questions about planting records are a good place to start.
Run the old and new side by side
Don't switch off the old tools on day one. Keep working the way your team does today, and bring what they capture into the new tool as it arrives, by regular import or an automatic connection, depending on the tool.
Running both lets you compare. Pick the reports you actually use, such as hectares planted this season, survival by site or the totals in your last funder report, and produce them from both. When they agree, or you understand every difference, the new tool has earned the switch. Not before.
Avoid two-way syncing while both run. When both tools can edit the same record, nobody knows which one is right. Let one be where records are created, and the other read from it.
Keep the field tools that work
Changing field tools adds training work, so start by checking whether the tools your team knows can stay. If your KoboToolbox or ODK forms work and your team knows them, keep them. Change the back office first: the records, the maps, the reports. The field team keeps filling in the same forms while the new tool takes in what they send.
Take stock, then test an export with a sample of your records.
Microsoft ExcelGoogle SheetsQGIS
The team keeps the forms it knows.
KoboToolboxODK
History and new captures go into the new tool. Produce the same reports from both.
Same forms; the new tool takes in what they send.
New records are created only in the new tool.
If the app changes, your lead trains the team on their own phones.
Old tools stay read-only, dated, for when someone asks where a number came from.
The new app, or the forms that already worked.
Some teams never switch their field app, and that's fine. Others switch once the new tool can do something the old forms couldn't, such as showing a crew last season's plot on the map before they walk to it. Either way, it's a choice, not a condition of adopting the rest. Our KoboToolbox alternatives guide compares the field apps restoration teams use.
Switch in the off-season
When the field team does switch, time it for a quiet moment: after planting and monitoring, or before a new group of field staff is trained. Changing apps during planting season can interrupt capture and leave gaps you can't fill later.
Train the trainer. Your lead learns the new app first, then trains the field team in their own language, on their own phones. Your team then has someone who can train new staff and answer questions, and the knowledge stays inside your organization.
Before the day, test on the phones your team actually carries: the oldest, cheapest Android, offline, out in the field. If it's slow there, fix it before everyone depends on it. And plan how people will sign in, because some field staff don't have an email address.
After the switch
Freeze the old tools rather than deleting them. Make them read-only, note the date you stopped writing to them, and keep them for as long as you might need to show where a number came from. A verifier or funder may ask years from now.
A good switch is a quiet one. Nobody in the field loses a day, every past season is still there, and you could leave if you had to.
If you're considering Restoration Scope, here is what switching to it looks like, step by step. Our pricing page explains the free pilot, where we bring in a sample of your records first.
Related guides
- Where restoration records live: from word of mouth to custom software, and where each level breaks.
- KoboToolbox alternatives: field apps for restoration and carbon teams, compared.
- A spreadsheet can look full and still be missing what matters: four tests for the records you have.
- Acción Andina: bringing many partners' planting records into one system.
Frequently asked questions
How long does it take to adopt new software?
Plan in weeks, not a single day. Setting it up can be quick. What takes time is running the old and new tools side by side until the new one gives the same answers, and waiting for a quiet moment in the season to switch the field team.
Do we have to clean up our spreadsheets before we switch?
No. Bring them as they are and keep the original files untouched. Flag doubtful records as they come in, and let someone who knows the project decide each one.
Will our field team have to learn a new app?
Not necessarily. If your KoboToolbox or ODK forms work, choose a system that takes in their submissions and keep them. If the field team does switch, switch it last, once the back office runs on the new tool, and preferably in the off-season.
How do we avoid getting locked in?
Test an export before you sign. Ask the vendor to bring in a sample of your own records, then export them back out as spreadsheets and spatial files, and check that records, boundaries, links and photos all come back.
Who should lead the switch on our side?
One person who knows the operation, is comfortable with spreadsheets and can make decisions. The vendor should do the heavy lifting; your lead makes the calls only your team can make.
