Digital Transformation

Which Door You Should Come In Through

The related services on this site are not tiers of one thing, and picking the wrong entry point wastes the first few weeks. Business process automation is the right start when the process is known, the systems are staying, and the problem is that a defined sequence of steps is done by hand. Selection consulting is the right start when a platform decision is genuinely open and has to be settled before anything can be built on top of it. The transformation engagement is the right start when nobody can yet say which of those two applies, because the pain is described by symptom rather than by step.

A quick self-test tells you which case you are in. Try to write the current process as a numbered sequence, with the system named at each step and the person who performs it. If you can produce that list, you already hold the input an automation or integration build needs, and you can go straight at it. If the list dissolves into "it depends" by step three, or two people in the room write different lists for the same job, that gap is the discovery work, and no build estimate means anything until it closes.

What Has to Be True Before a Connection Can Be Built

Every system in a chain has to expose a way in, and the three available ways in are not equivalent. A documented HTTP API with OAuth 2.0 is the good case. A scheduled file exchange, SFTP with CSV or a fixed-width extract, works and is often the only option for older line-of-business software, but it moves data in batches, so "real time" becomes "every fifteen minutes" and everyone downstream has to be told that number. Direct database access is the case to avoid: it bypasses the application's own validation rules and it breaks on the vendor's next schema change with no deprecation notice, because you were never a supported consumer.

Authentication is where integrations quietly acquire an expiration date. Access tokens are short lived and refresh on their own, which is fine, but the credential behind them is often a person. An integration authorized under an employee's login stops working the day that account is disabled, and nobody connects the two events for a week. Microsoft 365 and SharePoint work is the common example: an app registration in Entra ID with application permissions and admin consent survives staff changes, but its client secret does not, since the portal caps a custom secret lifetime at 24 months and a certificate is the alternative when you need longer. Either way the expiration date belongs in a calendar with a named owner, not in the integration's documentation.

Volume decides whether a sync can be immediate or has to be queued. Salesforce allocates API calls against a 24 hour rolling window sized by edition and license count, NetSuite governs both script usage units and concurrent connections, and most CRM APIs cap requests per short interval per application rather than per user. None of that matters for twenty records a day. It matters on the initial load, when five years of history goes through the same limit, which is why a backfill is normally a separate throttled job rather than the first run of the ongoing sync. The same trap exists on the document side, where SharePoint Online's 5,000 item list view threshold stops unindexed queries at production scale after passing every test at pilot scale. The checks worth running against each system before a design is committed:

• Whether API access is included in your subscription tier or sold as a separate module you do not currently own.
• Whether a sandbox or test company exists, and whether it is refreshed from production data or starts empty.
• Whether the vendor publishes webhooks or you will have to poll, and how often polling is permitted.
• Which fields involved are custom, since custom fields carry their own API names and their own permission settings.
• Who can grant the integration account its permissions, you or a reseller or a hosting provider, and how long that request takes them.

One Way, Two Way, and Who Owns the Field

The first design decision on any connection is direction, and it matters more than it sounds. A bidirectional sync is a materially bigger build than a one-way feed, and more to keep working, and a good share of the time nobody needed it. One-way means one system is the source for a given field and everything else displays a copy. Two-way means both sides can change the same value, which obliges you to define what happens when both do, before anything is written.

The unit of ownership is the field, not the record. It is normal and correct for the CRM to own the account name and the primary contact while the ERP owns credit terms, tax code, and the billing address, on the same customer. Writing that down as a field-level map is the least glamorous part of the work and the part that removes the most rework later, because it forces answers to questions like whether a salesperson may change a customer's payment terms from inside the CRM. That is a policy question wearing a technical costume.

Conflict resolution needs an actual rule. Last write wins is the usual default and it is fine where only one side realistically writes. Where both write, what holds up is source of truth per field plus a rejected-change log that someone reads. Deletes are the related surprise: most sync configurations handle creates and updates and quietly leave an orphan on the far side when a record is deleted, so decide early whether delete means delete, archive, or flag inactive.

Matching has to be decided rather than assumed. Two systems that have never spoken share no identifier, so the first sync must match existing records on something, and email address is the tempting choice that fails. Shared inboxes, people who change employers, and two contacts at one company with one address between them all produce wrong matches that are painful to unpick afterward. The durable approach is to write a stable external ID into a dedicated field on both sides during the initial reconciliation, then match on that, which also makes the sync safe to re-run without generating duplicates.

Cutover, Parallel Running, and Backing Out

Increments reduce risk only if each one can be reversed. In practice that means the old path stays available while the new one is being proved, and the two are compared on real transactions rather than on test data invented for the occasion. Parallel running is the honest version of a test plan: the same orders travel both routes for a defined period and someone who does the job daily compares the outputs. It costs duplicate effort for that period, and that duplicated effort is the whole point of it.

Decide what a rollback consists of before the cutover rather than during it. For a read-only feed, rollback is switching the feed off. For anything that writes, rollback means knowing exactly which records the new path created or changed inside the window, which is why write integrations should stamp the records they touch with a source marker and a timestamp. Without that stamp, backing out turns into manual reconciliation across an unknown set of records, usually under time pressure.

The failure with no technical remedy is the partial cutover that never finishes. A team keeps the old spreadsheet "just for now" beside the new system, both are half maintained, and reporting out of either one is wrong. Set an end date for the parallel period and treat the decision at that date, finish or revert, as a real decision with a named owner rather than an event that quietly fails to happen.

When a Smaller Fix Is the Right Answer

Problems described as transformation are sometimes answered by a connector the two vendors already publish for each other, a scheduled file drop, or one changed rule about who is allowed to approve what. Checking that first is worth the day it takes, because a native connector maintained by the vendor is one you never have to maintain, and it keeps working across the vendor's own upgrades instead of breaking on them.

Native connectors run out at predictable points. They typically sync a fixed field set, ignore custom objects, run in one direction only, or assume a one-to-one relationship between records that your business does not have. One customer in the CRM mapping to three billing entities in the ERP is the usual breaking point, and multi-currency or multi-company setups are the next. Those limits are worth identifying deliberately, before the native connector is in production and its gaps are being filled by hand.

There are also cases where nothing should be integrated yet. If the process is still changing week to week, an integration hard-codes a workflow that is not finished, which is a different problem from automating a broken process: the steps may be right, just not settled. If the data on one side is already distrusted, a sync spreads the distrust rather than resolving it, and the cleanup is the prior job. And where volume is genuinely low, a person handling six records a day is not the constraint, while an automation of those six records is something that has to be maintained, monitored, and re-tested every time either vendor changes an API.