Why there is nothing to map to
A Checkpoint writes process state to the engine’s database so that, after a crash, the job resumes from that point rather than from the beginning. Camel has no process state and no resume: a route either completes or it does not. Any converter that claims to migrate Checkpoint automatically is either wrong or quietly changing your delivery guarantees.
The three answers
Accept at-least-once and make the work idempotent. The cheapest and, in most estates, the most honest. Most Checkpoints exist because someone feared duplicate processing; an idempotency key on the downstream operation solves the same problem with far less machinery.
Externalise the state machine. Split the process at the Checkpoint boundary into separate routes joined by a durable queue. The broker becomes the recovery point. This is the closest structural equivalent and usually the right answer for long, multi-step business processes.
Persist an explicit saga. For processes with genuine compensating actions, model the steps as a saga with a persistent store. The most work, the most faithful, and only worth it where a partial failure has to be actively undone rather than retried.
How to decide
Read what happens after the Checkpoint. If the following activities are idempotent, take the first answer and delete the machinery. If they are not, look at whether the process is genuinely long-running or merely long. The first calls for a queue boundary, the second usually just needs a retry policy.