Somebody enters an order into one system, then enters the same order into a second one. It is the most automatable task on the list and the one where projects most often stall, because the hard part is not the moving. It is deciding what counts as the same record.
Mapping is the part everybody pictures: this field over here goes into that field over there. It is genuinely straightforward when both systems have an API, and it is where the 70 to 90 percent share in the calculator comes from. The work is tedious rather than difficult, and it is finite: a mapping done once keeps working until somebody changes a form. Most of the value of an automation project is delivered by this half, which is why it is worth doing even when the second half is messy.
The second system usually already has some of the records. So a build has to answer, for every row: is this a new record or an update to an existing one? Businesses answer that with an email address, a customer number, a phone number, or some combination, and every one of those is unreliable on its own. Two people share a family email address. A customer number was retyped with a transposed digit in 2019. A phone number was stored with a country code in one system and without it in the other. This is the work that makes a rekeying project take three weeks rather than three days.
The important design decision is what a build does with an ambiguous record, and there are only two honest answers: refuse and queue it for a person, or merge and risk creating a wrong record. Refusing is almost always right. A duplicate customer record is a nuisance; a merged one that combines two real customers is a genuine problem that surfaces months later in a bill sent to the wrong person. A build that quietly merges on a fuzzy name match will look better in its first week and worse in its first year.
One-way sync, where system A is the source of truth and system B follows, is a well-understood problem with a clean answer. Two-way sync, where either side can change a record, is a different and much larger problem: two people edit the same customer in two systems in the same hour and something has to decide which edit wins. Most businesses that ask for two-way sync actually want one-way sync plus one specific field flowing back. Establishing that is usually the single most useful hour of an audit.
Whether both systems have documented APIs on the plan you actually pay for. Which system is the source of truth for each field, written down, because the answer is often different for different fields. And what your current duplicate rate is, which nobody knows until they look. If the second system is a desktop application with no API, the honest answer is usually that this is not worth automating, and the calculator will say so.