Importing sites

Benbow can read the site list of the tool you use today and create one Benbow site per host, with the same name and the same folder. Your files stay where they are: nothing is copied or moved. The source tool is only read, never modified, and can keep running next to Benbow.

Start with a dry run

benbow import mamp --dry-run    # what would be created; changes nothing
benbow import mamp              # create the sites

The same works for every source:

benbow import local --dry-run
benbow import herd --dry-run
benbow import valet --dry-run
benbow import xampp --dry-run

To import only some sites, repeat --site with the host name or the site name:

benbow import mamp --site shop.local --site blog.local

In the app: File → Import from Another Tool…, then pick the source, the sites to import and, if you want, “Also migrate”.

Sources

Source	What Benbow reads	Sites
MAMP PRO	a temporary copy of its settings file	virtual hosts
Local	~/Library/Application Support/Local/sites.json	each site, served from app/public
Laravel Herd	~/Library/Application Support/Herd/config/valet/	parked folders, linked sites and isolated PHP versions
Laravel Valet	~/.config/valet/	parked folders, linked sites and isolated PHP versions
XAMPP	/Applications/XAMPP/xamppfiles/etc/extra/httpd-vhosts.conf	virtual hosts

For MAMP PRO, Benbow copies the settings file into its own folder, reads the copy and deletes it, so the original is only read once.

Domains

Imported sites keep their names: .local names (common with MAMP PRO) and the .test names of Herd and Valet. Benbow serves those suffixes once you enable them, or you can switch to .localhost:

benbow domains enable local     # keep .local names (one admin authorization)
benbow domains enable test      # keep .test names (one admin authorization)
benbow import mamp --localhost  # or serve them as <name>.localhost instead

.localhost needs no setup at all. See HTTPS for what enabling .local or .test changes on your Mac.

A host without a reserved suffix (for example intranet) becomes intranet.local, with a warning. MAMP’s default localhost host is skipped.

What gets imported

From the source	In Benbow
host name	site name and domain (blog.client.local becomes site blog-client)
document root	the same folder, used in place
PHP 8.x	the same minor version
PHP 5.6 to 7.4	the same version on Apple Silicon with macOS 15 or later, otherwise PHP 8.1 with a warning
no PHP version	the newest fully supported version, with a warning
SSL setting	ignored: every Benbow site is HTTPS
aliases	imported, unless another site already uses them

A host is skipped when its folder does not exist, when its name is not a valid host name, or when a Benbow site already uses the domain. Running the import again only adds what is missing. All sites of one import are created together: if one fails, none is kept.

Old PHP versions are end of life. Run benbow php check <site> to see what would break on a newer one (see PHP).

Databases without migration

A plain import leaves each site’s database settings as they were, so the site still talks to the source tool’s database. For MAMP PRO there is one convenience: if MAMP linked exactly one database to a site and a database with that name already exists on Benbow’s MySQL, the new site is linked to it.

Assisted migration

With --migrate, Benbow moves each new WordPress or Laravel site to work entirely from Benbow:

benbow import mamp --migrate --site shop.local
benbow import local --migrate

For each site, in one step:

1. The database is copied from the source tool’s MySQL into Benbow’s MySQL. The source is only read, and it must be running: Benbow never starts or stops it.
2. The site gets its own MySQL user, with the password in your login keychain.
3. wp-config.php (or .env) is backed up to Benbow’s folder, then only the database settings change: DB_NAME, DB_USER, DB_PASSWORD and DB_HOST (for Laravel, the DB_* keys and APP_URL). If Benbow cannot find each of those lines exactly once, it changes nothing. For other PHP sites, Benbow shows the values to set yourself.
4. For WordPress, the old address is replaced with the Benbow address in the database, with serialized data handled correctly.

Benbow connects to the source with the credentials in wp-config.php or .env. To use others, pass --source-user and --source-password (asked on the terminal). They are used for that copy only and never stored.

To load a dump file instead of reading the source’s MySQL, for one site:

benbow import mamp --migrate --site shop.local --dump ~/Backups/shop.sql.gz

If Benbow already has a database with the same name, --existing use (the default) uses it, --existing recopy copies it again after a backup, and --existing skip leaves it alone.

If a step fails, everything that site’s migration did is undone. Other sites carry on.

The folder stays shared

Migration does not copy your project. After it, the site works from Benbow, and the source tool’s copy of the same folder no longer reaches its database, so it would show old data.

Undo a migration

benbow import undo shop

This restores wp-config.php or .env from the backup and deletes the database Benbow copied, with its user. The site stays in Benbow. In the app: Undo Migration in the site’s Advanced section.