ClonePartner Envoy: the on-prem migration agent

Before we dive into what ClonePartner Envoy is, it helps to be aware of how ClonePartner and most cloud-hosted solutions run migrations today -

How ClonePartner runs migrations today

Most of our customers start with the standard hosted model because it is faster to get going and more cost effective.

Today’s standard pipeline looks like this:

1. Data is pulled from the source system using official APIs or exports.
2. It is stored in a migration database hosted in the EU.
3. Truto, our data transformation layer, performs all the mapping, cleaning, and reshaping.
4. Data is then pushed into the destination system.
5. Migrations are monitored and validated by our engineering team.

This model is already built for security conscious teams:

• ClonePartner is audited against SOC 2 Type II, which focuses on controls around security, availability, processing integrity, confidentiality, and privacy. 
• Our information security program is aligned with ISO 27001, the leading standard for information security management systems.
• Our processes are built to respect GDPR, HIPAA, and similar privacy and security regimes that require strong administrative, technical, and physical safeguards for personal and health data. 

For many mid-market and a good number of enterprise customers, this is sufficient and significantly simpler operationally.

But some security teams have a hard requirement:

“The data cannot leave our VPC or data center. Not even temporarily. Not even to an EU-hosted migration database.”

That is exactly the problem Envoy solves.

Introducing ClonePartner Envoy: an on-prem migration agent

ClonePartner Envoy is a deployment option for customers with strict data residency, regulatory, or internal risk requirements.

At a high level:

• You receive an executable file (or container image) from ClonePartner.
• You run it inside your own environment (VPC, on-prem, private cloud).
• It connects only to:
• • the source system, and
  • the destination system.
• No data is ever sent to, stored on, or processed inside the ClonePartner infrastructure.
• Logs are generated locally and never leave your infra unless you decide to share them.
• No one at ClonePartner, including the migration engineer who authored the executable, can see your data.

From a CISO’s perspective, Envoy behaves like an on-prem agent that executes a predefined migration playbook, with all the logic baked into it, but with zero persistent vendor data access.

How Envoy works under the hood: migrations as if your own team built them

Think of Envoy as a compiled version of a typical ClonePartner migration pipeline.

1. We design the mapping with you
2. • Which objects are in scope (tickets, deals, contacts, users, attachments, custom entities).
   • How fields map (one-to-one, many-to-one, or via transformations).
   • How to handle edge cases, historical data, and custom workflows.
2. We encode the mapping and flows into a self-contained executable
3. • Schema mapping
   • Transformation rules (what Truto usually does)
   • Rate limiting and retry behavior
   • Validation rules
   • Logging and observability hooks
3. You deploy and run Envoy inside your environment
4. • On your own VM, container cluster, or bare metal.
   • Using your own network policies, secrets management, and IAM.
4. Envoy talks directly to your systems
5. • Outbound calls only to the source and destination APIs or data stores.
   • No calls to ClonePartner servers.
   • Optional calls to your internal logging or monitoring stack (SIEM, APM) if you choose.
5. Debugging happens via redacted logs
6. • Envoy writes local log files that contain no raw data, only:
   • • error codes,
     • field names,
     • identifiers that you are comfortable exposing (or hashed references),
     • stack traces and technical details.
   • Your team reviews and optionally masks anything they consider sensitive before sharing logs with us.
   • We reproduce the issue using synthetic data and ship you a new executable if needed.

The net effect: ClonePartner sees behavior, not data.

Why legal, security and compliance teams care

Security and compliance leaders are increasingly wary of data leaving their control, especially to third party SaaS tools and cloud providers. Surveys show a significant portion of CISOs feel cloud providers overpromise on security, and many are actively changing providers to reduce perceived risk. 

At the same time, regulations such as GDPR and India’s DPDP Act place strict controls and obligations on cross border data transfers and third party processing. These regimes require either adequacy decisions, contractual safeguards (like SCCs), or strong technical and organizational measures when personal data leaves its region or primary controller. 

Envoy makes that conversation much simpler:

• Data never leaves your environment, so no additional cross border transfer mechanism is needed for the migration itself.
• Your existing HIPAA, GDPR, DPDP, or ISO 27001 controls continue to apply, because Envoy runs inside your system boundary and under your logging, access control, and monitoring regime. 

In practice, Envoy becomes a strong answer to questions like:

• "Where exactly does this data go during the migration?"
• "Who can access it at any point in time?"
• "Do we need a new cross border transfer assessment just for this project?"
• "How do we prove that this vendor does not retain a copy of our data?"

What's included in the deliverables?

Envoy is not a black box. It is a program with three key concepts:

1. A configuration file
2. A secret store integration
3. A JavaScript runtime based migration engine

1. Configuration file: what to move and how to monitor it

The executable you receive accepts a configuration file that your team can read and version control.

In that config you define:

• Resources to sync
• • Which objects: tickets, users, contacts, deals, notes, attachments, custom entities
  • Which subsets: date ranges, status filters, archived vs active, etc.
• Speed and batching
• • How quickly to sync resources
  • Batch sizes and pagination settings
  • Retry intervals and limits
• Health checks
• • HTTP health check endpoints that your monitoring stack can ping to ensure the process is alive
  • Status endpoints you can hook into Prometheus, Datadog, New Relic or similar
• Notifications
• • Optional integrations so you can, for example, receive alerts on Slack or Microsoft Teams when:
  • • a run starts or finishes
    • error rates cross a threshold
    • specific resource types fail too often

The config is what binds Envoy to your operational reality: how aggressive you want to be, how you monitor, and how you get notified.

2. Secrets: encrypted at the OS level, not in files

Credentials are often the scariest part for security teams.

Envoy ships with a CLI that includes a secret subcommand. Your team uses that to inject secrets such as:

• OAuth client IDs and secrets
• API tokens
• Service account credentials

Key points:

• Secrets are not stored in config files
• Secrets are not stored in .env files
• Secrets are stored encrypted at the OS level using the platform’s secure credential store
• Only the Envoy program has access to them at runtime

So your runbook looks like:

1. Provision a host or container
2. Install Envoy
3. Use the CLI to set credentials into the OS level store
4. Keep the config file free of raw secrets

When you run Envoy, it:

• Pulls secrets from the OS key store
• Fetches access tokens (for example OAuth) as needed
• Reads the configuration file
• Starts the migration immediately on that machine

3. Runtime model: single threaded code, multi threaded IO

Envoy uses a JavaScript runtime under the hood.

That gives you:

• A single threaded event loop for the migration logic
• Highly concurrent, multi threaded I/O for all network calls and disk operations

In practical terms:

• The code that decides “what to do next” is single threaded and deterministic
• All the heavy lifting - API calls, reading/writing temporary files, etc - is handled by a multi threaded I/O layer

Result: you get excellent throughput on API calls and disk operations without the complexity of managing your own worker pool.

Where the data lives during an Envoy migration

Everything is local to the machine where Envoy runs:

• API calls from the source terminate on that host
• Temporary data is buffered and processed on that host
• API calls to the destination originate from that host

There is no hop through a ClonePartner controlled environment. The ingress and egress points are inside your own perimeter.

Key considerations before choosing Envoy

Envoy is powerful, but it is not always the first or easiest choice. There are tradeoffs that matter, especially to engineering and operations teams.

Below is an expanded list of considerations to evaluate with your stakeholders.

1. Manual mapping effort (on ClonePartner's end)

Because Envoy is a compiled, self contained executable, all mappings are written explicitly before the agent ever runs in your environment.

• Every object type, field, and custom object must be defined upfront.
• Transformations that would be configured in a UI in the hosted model are now expressed as code or configuration embedded into the binary.
• Late stage changes (for example "we added 5 new custom fields last week") require a new build and redeploy.

Impact:

• More time in discovery, design, and mapping workshops.
• More iteration in non production or sandbox environments before production cutover.
• Higher upfront cost that pays off in very high comfort levels for security and compliance.

2. Customer responsibilities and internal ownership

With Envoy, you own the runtime.

Your teams will typically be responsible for:

• Provisioning the compute resources (VM, container, or on-prem host).
• Providing and rotating API keys, service accounts, or database credentials under your own secrets management.
• Managing network controls (allow lists, VPC endpoints, proxy settings).
• Triggering and monitoring runs (for example via cron, CI, or manual execution).
• Capturing logs and shipping them to your SIEM or log analytics stack.

This gives you greater control, but it also means:

• Security engineering or platform teams are usually involved from the start.
• There is a clear RACI around who "pushes the button" and who monitors the migration run.
• There might be internal change management overhead if a CAB or similar body must approve new binaries or scheduled jobs.

3. Observability, logs, and PII handling

Because ClonePartner cannot see production data, logs are the main collaboration surface.

Good practice includes:

• Configuring log levels (info, warn, error) in a way that balances debug depth with sensitivity.
• Logging field names, object IDs, internal error codes, and sample counts, but not full values.
• Using hashing or tokenization for any identifiers that must be shared externally for troubleshooting.
• Forwarding all logs to your SIEM so your SOC can monitor patterns during the migration window.

Your team can then selectively redact or mask log excerpts before sharing them with us for support.

4. Performance, scalability, and resource planning

In the hosted model, ClonePartner manages performance tuning, parallelism, and infrastructure scaling.

With Envoy:

• You decide how much CPU, memory, and network bandwidth to allocate.
• You can run multi threaded, multi worker, or batched migrations based on your own constraints.
• You can throttle migrations during business hours or run at full speed in predefined windows.

It is important to plan for:

• Non production test runs on representative data volumes.
• Understanding how long full runs and delta runs will take with your chosen resource profile.
• Any impact on source and destination rate limits or throttling.

5. Security architecture and threat model

From a threat modeling point of view, Envoy helps:

• Reduce the number of external processors of your data.
• Keep sensitive data within your existing network, encryption, and IAM controls.
• Align more easily with zero trust and data minimization principles.

Security teams should still review:

• Where the binary will run (isolated subnet, dedicated host, hardened base image).
• How access to that host is managed and audited.
• How binaries are verified (checksums, signatures) before deployment.
• How secrets are injected (for example via environment variables, vault integrations, or secret managers).

6. Regulatory posture and auditability

For regulated industries, auditors will likely ask:

• "Who is processing the data?"
• "Where is it processed?"
• "What controls apply?"

Envoy simplifies many answers:

• Processing stays within your own ISMS, which already maps to ISO 27001 and other frameworks. 
• You can document Envoy as a controlled internal tool with clear access controls, logs, and change management.
• You avoid the need for additional cross border transfer tooling just for the migration, which can be sensitive under GDPR and DPDP. 

If you process health data, Envoy also fits naturally into the HIPAA Security Rule expectation that covered entities maintain administrative, technical, and physical safeguards for electronic protected health information inside their own environments. 

7. Change management and iteration speed

Because every change to the mapping or behavior requires a new executable:

• It is wise to treat the mapping specification as a controlled artifact, with versioning and approvals.
• A dedicated UAT phase with realistic data and scenarios is essential.
• Feature requests like "can you also dedupe these two fields" are still feasible, but they go through a defined release cycle rather than an on the fly config change.

This is one reason Envoy projects take longer and cost more than our standard hosted migrations. You are trading flexibility and speed for an extremely tight security and data residency posture.

Envoy vs standard ClonePartner migrations: how to choose

A short way to think about it:

• Choose standard ClonePartner migrations when:
• • You want the fastest time to value.
  • Your security team is comfortable with a highly controlled, audited third party processor that is SOC 2 Type II, ISO 27001, GDPR and HIPAA aligned.
  • You are happy to leverage our hosted transformation and monitoring infrastructure.
• Choose ClonePartner Envoy when:
• • Your policy or regulator explicitly requires that data does not leave your VPC or physical environment.
  • You cannot wait on extensive vendor assessments and reviews to bring ClonePartner onboard.
  • Your CISO or DPO wants to minimize third-party data exposure as a matter of principle.
  • You handle extremely sensitive datasets where any new external processor would trigger disproportionate review effort.
  • You are comfortable investing a bit more time and budget upfront to keep all processing in-house.

Many customers start on the standard model, prove out the migration approach, then move to Envoy for specific workloads or later phases that warrant the extra security posture.

What a typical Envoy project looks like

1. Scoping and risk alignment
2. • Security, data protection, and engineering stakeholders align on scope, constraints, and goals.
   • We confirm whether the standard hosted model is sufficient or if Envoy is the right default.
2. Mapping workshops
3. • Deep dive into your current and target schemas.
   • Document all field mappings, transformations, filters, and edge cases.
   • Agree on acceptance criteria and reconciliation rules.
3. Prototype and test binary
4. • We build an initial Envoy executable against your sandbox or non production environment.
   • Your team runs it inside a test VPC or lab network.
   • Together we validate logs, error handling, and performance.
4. Hardening and rollout
5. • Your security team reviews and approves the deployment pattern.
   • We perform dry runs on production like slices of data where feasible.
   • Change tickets, runbooks, and rollback procedures are documented.
5. Production cutover and validation
6. • Migration runs in controlled windows, with joint monitoring.
   • Reconciliation and sign off are done against agreed thresholds.
   • Envoy binaries are retired or archived according to your policies when the project is complete.

Why legal, compliance and privacy teams like Envoy

Under GDPR and similar laws, international transfers of personal data trigger additional requirements: adequacy decisions, standard contractual clauses, or other safeguards when data leaves the EEA or its primary region. 

Under HIPAA, the Security Rule expects covered entities and their business associates to maintain appropriate administrative, physical and technical safeguards for electronic protected health information wherever it is created, received, maintained or transmitted.

Envoy simplifies those conversations:

• You are not adding a new external processor for the migration data itself
• You keep processing within established boundaries that are already covered by your ISMS and BAA framework
• Audit trails, access controls and monitoring all stay under your existing tooling

So instead of writing a new chapter in your DPIA for “third party migration database in another region”, Envoy often fits into your existing “internal processing” model with a smaller delta.