The short version
- We hold a copy of your website so that we can move it. That copy is yours. We delete it when you ask.
- We do not run ads, we do not track you around the internet, and we do not sell anything about you or about the people who visit your site.
- A small number of outside companies help us do the work — hosting, payments, email, and the assistant that helps with the migration. They are named further down, with what reaches each one.
- If you want to know what we hold, or want it deleted, email hello@embarkeasy.com and a person will answer.
Who we are
Embark is a website migration and hosting service operated by Minuscule Ventures, LLC, registered in the State of Delaware (“we”, “us”). Minuscule Ventures, LLC is the company responsible for the information described on this page. You can reach us at hello@embarkeasy.com.
What we collect
What you hand us
The address of your WordPress site, your name and email address, whatever you type into the migration chat or a support message, and the access we need to make a copy: an export file, a database dump, a ZIP of your site files, a hosting login, or a key generated by the small Embark connector plugin you install on your own WordPress site.
What arrives with your site
A copy of a website is a copy of everything in it: pages, posts, images, PDFs, menus, settings, form submissions, comments, member or customer records, and the list of user accounts that could log in. Some of that is personal information about your people rather than about you. We treat all of it as yours. We use it to build and run your migrated site and for nothing else — not to market, not to build a profile of anyone, not to sell.
What the connector plugin sends
If you choose the connector plugin, it sends your posts, pages, attachments and custom post types with their meta and taxonomies, and — on a separate button — a fixed list of plugin settings: the wp_options rows an Embark feature knows how to translate, named one at a time. It does not read your own database tables. WooCommerce orders and addresses, membership records and transactions, form entries, subscriber lists and redirect logs stay on your server.
An earlier version of the plugin did copy those tables here. That was wrong and it is over: the address it sent them to now refuses them, and the stored copies are deleted by a one-off clean-up we run against the live database. If you want to know whether yours are gone yet, email us and a person will check and tell you. We would rather say that than write “deleted” on a page and leave you to assume it.
The plugin also leaves your API keys, tokens and passwords behind. A setting whose name says it holds a credential is never sent. A setting whose name looks innocent but holds a key one level down — a mail plugin’s SMTP password, a security plugin’s API key — has that part removed before sending, and removed again when it arrives here, because the plugin running on your site may be an old build. The same clean-up deletes the ones an old build already sent.
What we record automatically
Our servers keep ordinary request logs: the time, the address requested, the browser’s user agent, and the IP address the request came from. We use them to find faults and to block abuse. We also keep a record of the steps of your migration — what was copied, what failed, what the assistant did — so that both of us can see what happened and when.
Here is what is not in that list, and never will be while we run this: no advertising cookies, no third-party analytics script, no tracking pixel, no ad network, no data broker, no cross-site profile. We do not sell or rent personal information to anyone, and we do not have an advertising business of any kind to feed.
Cookies
We set a cookie when you sign in to your site’s admin, so that you stay signed in. A preview needs no sign-in: its link is based on your domain name, so it is not a secret, and search engines are told not to list it. Do not put confidential content in a preview. That is the whole list; there is no cookie banner because there is nothing to consent to.
Why we hold it
- To do the migration you asked for — copy the site, rebuild what the plugins used to do, and show you a preview.
- To run your site, under the hosting arrangements you agree with us. Apart from the copy of your images and files described under how long we keep things, automated backup scheduling, retention and one-click restore are not a verified service; keep an independent backup.
- To answer you when you email or open a support ticket.
- To charge you the migration fee and, if you have one, the monthly plan.
- To keep the service standing up — finding faults, stopping abuse, and preventing fraud.
- Because the law sometimes requires it, mainly the records of what you paid and when.
Who else touches your data
We keep this list short on purpose. These are the only companies your information reaches as part of running Embark.
| Company | What it does for us | What reaches it |
|---|---|---|
| Cloudflare | Hosting, databases, file storage, CDN and DNS. Everything we run, runs there. | Your site’s content and files, our request logs, and the traffic between your visitors and your site. |
| Stripe | Takes payments and issues refunds. | Your name, email address, billing address, and the card details you enter on Stripe’s own form. We never see or store a full card number. |
| Resend | Delivers the email we send you. | Your email address and the contents of that message. |
| Cloudflare Workers AI | Runs the language model behind the migration assistant. It is an openly published model that Cloudflare hosts on its own network, so the request goes to Cloudflare, not to the company that published the model. | What you type into the assistant, plus the slices of your site’s content and settings the assistant needs to read to answer. |
| OpenRouter | Used only when we choose a model Cloudflare does not host, for one site’s assistant or for everyone’s. It passes the request on to the company that runs that model. | The same as the row above, for the sites using it. |
| Google Fonts | Serves the typefaces on our own pages. | Your browser’s IP address and user agent, when it downloads a font. Google Fonts sets no cookies. |
The assistant deserves a plain sentence of its own. It is an AI model, by default run for us by Cloudflare; the OpenRouter row above says when it is not. We send it the smallest slice of your site we can get away with, and we ask our providers not to keep those prompts or use them to train models. We can read their contracts; we cannot inspect their machines. So assume anything you type into the assistant is seen by the company that runs the model.
Your WordPress login does not go through the assistant
There is a panel under the message box called Connect your WordPress with three fields: the site address, the username, and the WordPress password you sign in with. It posts to its own address, and what you put in it is written straight into storage that expires after an hour. It is not turned into a chat message. It is not added to the conversation we keep. It is not sent to the model — not the value, and not a reference to the value. When the step that needs the login runs, our own server puts it into that step, here, and throws it away again. That step is our own browser signing in at your site’s login page, over https, to download your WordPress export file; the password is typed into that page and sent nowhere else. That is why we can tell you the assistant never sees it: it is not a filter we run, it is a path the credential does not take.
It needs your real password, not an application password, because WordPress accepts application passwords only from other programs and never on its login page. It will not work if signing in to your site also asks for a code (two-factor login). If you would rather not hand over a password at all, you do not have to: download the export file yourself and attach it, or install our connector plugin, and you never give us a login. If you do use the panel, you can change your WordPress password once your content is across.
So: use that panel, and do not type a password, key or token into the message box. If you do it anyway, three things happen. The message is scanned and anything that looks like a credential is replaced with a one-hour reference before the message is stored or sent anywhere — that is a real safety net and we test it against a list of the shapes we know, but it is a scan of ordinary prose and we will not promise you it recognises every one. The copy we keep of the conversation stores the scanned version, not what you typed. And what you typed does reach the model for that one turn, because that is the turn it was part of.
We will not dress that scan up as more than it is, so here is the part most policies leave out. What you type is prose, and no rule can certify a sentence to be free of secrets. The scan knows a list of shapes; the next password somebody invents is not on it. What we do about that is not a longer list — it is time. Every time we load your conversation to send it on, we run the scan over the stored copy again, so a shape we learn next month is removed from what we already hold without anyone re-typing it. Only the most recent part of the conversation is sent to the model at all, so something you typed on the first day stops being uploaded again on the fortieth. And the words we store have a limit on how long they stay: once it is switched on for this installation, the default we ship is thirty days, after which the text of an old message is deleted and only its shape — who spoke, which step ran, how long it was — remains. When you come back to your migration from the link we e-mailed you, the page shows you that same stored copy: the scanned version, with anything the scan replaced shown as [redacted], and only the words that limit has left. Anyone you forward that link to can read it too, so keep the link to yourself.
One more honest line, because it is the part none of that reaches: our servers keep ordinary request logs for 7 days, and a request log can contain the body of the request that made it. If you have already typed a password into the chat, treat it as disclosed and change it. We would rather tell you that than let the paragraphs above read as a guarantee they are not.
What we write down about a migration
The step-by-step record of your migration is not a copy of the conversation. Each kind of step has a fixed, named list of things it may record — how many pages were copied, how many failed, how long something took, the address of a page, a status code. Nothing on any of those lists is free text. A field there can be an identifier, a count, a yes/no, a status code or a web address with the secret half of it removed; it cannot be a sentence, which means it cannot be a sentence the assistant wrote or a sentence you typed. That is a rule the code cannot break rather than a rule it remembers to follow.
Two things that record used to be able to hold, and now cannot. An identifier on one of those lists — a page address, a storage key, a reference number — is only written down when it is one we issued or one already on your own record, because a licence key or an API key is shaped exactly like an identifier and the list could not tell them apart. And when the assistant hands your migration to a person, the ticket it files and the alert e-mail we send ourselves carry the reference, your site, the category of problem and a LINK to the conversation — not the conversation. The person reads your words in the conversation itself, behind our own sign-in, where the thirty-day limit and the re-scan above both apply.
A support ticket is a record of the request, not a copy of it
The same rule now covers the whole of a support ticket, and not only the ones the assistant escalates. A ticket holds no words. The subject we store is composed from your site and a category — not the subject line you typed; the note we store about a proposed fix says which of our tools it would run, how big the explanation was and where to read it — not the explanation. What you typed, what the assistant wrote back, and exactly what it proposes to change are all kept, and kept together, in two places: the conversation on the ticket, and the proposal we attach to it. Both need a sign-in to read — yours, or ours — and you can read either of them for your own site whenever you like.
Why the split: the ticket record is what shows up in lists, in the e-mail we send ourselves and in the live updates your support page receives, and each of those is a copy in a new place. The conversation and the proposal are read one at a time by somebody who has proved who they are, and they are deleted on the schedule below without anybody having to remember to do it.
We will also hand over information if the law genuinely requires it — a court order, for instance. If we are allowed to tell you first, we will.
If Embark is ever sold or merged, your information moves with the business, under this same policy until we tell you otherwise. We will tell you before that happens.
How long we keep it
- The export and the staged copy of your old site: the draft retention target is the migration period and 90 days after cutover, followed by deletion. This is not a verified automated retention, deletion or restore service. Agree on retention arrangements and keep your own backup.
- Your migrated site and its database: for as long as your site is with us, and for 30 days after you cancel, so that you can change your mind or collect a full export. Then deleted.
- Backup copies of your site’s images and files: from the moment we copy your site’s images and files across, and for as long as we host it, we keep a second copy of each of them in the same Cloudflare account. When you replace or delete a file, the old version stays in that backup for 30 days by default, so that a mistake can be undone, and is then deleted. When your site’s files are deleted after you cancel, their backup copies are deleted the same number of days later.
- Support conversations and the fixes proposed on them: two years, so that the next person who helps you can read what happened last time. That limit is not a promise we keep by hand — a job runs continuously and deletes support messages and proposals older than it, whether or not anyone ever looks at them. The ticket record itself outlives them, and holds no words to outlive.
- The migration chat with the assistant: the text of a chat message has its own, much shorter limit once the retention window is switched on: thirty days by default, after which the words are deleted and the record of the step is what is left.
- A Cloudflare token for a move to your own account: kept only sealed, so that the person who moves your site can open it and our servers cannot. Deleted from our database when they open it, when your site is live, or after 48 hours, whichever comes first. The database’s own recovery history can hold the sealed copy for up to 30 days after that, and only our operator’s key opens it.
- Request logs: 7 days.
- Billing records: as long as tax law requires us to keep them, usually seven years. Stripe keeps its own copy under its own policy.
Ask us to delete something sooner and we will, except for the billing records we are required to keep.
What you can ask us for
You can ask for a copy of what we hold about you, ask us to correct it, ask us to delete it, or ask for your site’s content as a file you can take elsewhere. Email hello@embarkeasy.com. It is free, a person does it by hand, and we aim to be done within 30 days. There is no portal to log into and no form to fill in.
If you are in the UK or the European Economic Area, the law gives you those rights by name, along with the right to object to some processing and to complain to your data protection authority. Our legal bases are the contract between us (doing the migration and running your site), our legitimate interests (keeping the service safe and working), and our legal obligations (tax records). If you are in California, we do not sell or share personal information as those words are defined there, and we will not discriminate against you for exercising a right. We honour these requests for everyone, wherever you live, because sorting customers by passport is a silly way to run a small company.
The people who use your site
When your site holds records about other people — members, donors, customers, people who filled in a form — you are the one who decided to collect them. In data protection language, you are the controller and we are a processor acting on your instructions. We do not contact those people, we do not use their details for our own purposes, and we do not sell them. If one of them asks you for their data or asks you to delete it, tell us and we will help you do it. If you need a signed data processing agreement for your files, email us and we will sign one.
Children
Embark is sold to site owners, and we do not knowingly collect information from children. If your own site holds records about children, that remains your responsibility to handle lawfully; tell us if it needs special treatment.
Security
How the data is protected — a separate database and file store per site, TLS everywhere, and the list of things we deliberately do not claim — is on the security page.
Changes to this policy
If we change this policy we change the date at the top. If a change actually matters to you, we email customers before it takes effect rather than quietly reposting the page.
Contact
Minuscule Ventures, LLC — hello@embarkeasy.com. Weekdays, usually the same day.