# How to migrate to Facteur

> What changes in a test when you change email testing tool, line by line, and what does not.
> https://facteur.eu/en/migrate

## Your tests keep their shape

The cost of changing email testing tool is not the subscription: it is the day spent rewriting assertions that already worked. Here it is the three lines that talk to the provider that change. Your test still waits for a message, and still asserts something about what it holds.

- Three lines per file: the import, the client, the call that waits for the message
- Nothing to export: test messages are regenerated by the next run of the suite
- Both tools side by side while you compare, with nothing to cancel

## The same test, at one provider then the other

The example starts from Mailosaur, the tool most migrations come from. From Mailtrap, MailSlurp, Mailisk or Mailpit the shape is the same: each tool has a page giving the field-by-field mapping.

## With our library, or by calling the API

The library buys comfort, not capability: everything it does, an HTTP call does too.

- **The library, if a dependency is fine** : One command, and it has no dependencies of its own. The client reads the key from FACTEUR_API_KEY, and its waitFor call holds the connection open until a message matches: no polling loop to write, no sleep to calibrate.
- **The direct call, if it is not** : A POST request to /v1/messages/search with a wait field in milliseconds, and the answer arrives when the message does. That is exactly what the library does, with nothing installed.

## Five steps, none irreversible

The first test moves in ten minutes, and it tells you whether the whole suite will move.

- **Create an account and an inbox** : An inbox is a mailbox that receives, which your tests query by its id. The free plan is enough to validate the migration, and asks for no card.
- **Put the API key in your environment** : Under the name FACTEUR_API_KEY, next to your current tool’s. The two live side by side: nothing asks you to remove the old one before you are convinced.
- **Move a single test** : The one that costs you most when it is flaky. Three lines to change, then you run it: if it passes, your suite will pass. That is the moment of truth and it does not take a day.
- **Run both suites in parallel** : For a week, long enough to compare pass rates on your own tests rather than on a sales page. It is also what makes going back free.
- **Set your ceilings and alerts** : A message ceiling per inbox, and a threshold that warns before it is reached: a test that runs away stops at its own limit instead of eating the whole team’s capacity.

## What is specific to the tool you are leaving

Each page carries the field mapping, what has no equivalent here, and prices read on a date written in plain sight.

- **Mailosaur** : The endpoint conversion table, one by one, and which of them are not open yet.
- **Mailtrap** : Moving from a sandbox that intercepts to an inbox that really receives.
- **MailSlurp** : What becomes of an inbox created then deleted on every test, and of per-operation billing.
- **Mailisk** : The cheapest on the market against ours, on the same monthly volume.
- **Mailpit** : Leaving a local interceptor: what you gain, and what you lose by no longer hosting everything.

## Known limits

What your current tool does and we do not do yet. Written here rather than discovered halfway through a migration.

- Downloading the raw message as .eml is not open.
- Deliverability analysis (SPF, DKIM, DMARC, spam score) is not open.
- Rendering previews across mail clients and the visual template editor have no equivalent, and will not: it is not the same product.

If your suite depends on one of these, write to us at

## Common questions