⇄Switching from another system

The order that has proved itself — and the most important point is right at the top:

1. The old system stays on. Until the very end. A switch with a way back is a different process from one without.
2. Take over a small sample — fifty contacts, one page. That shows you what the result looks like before you read everything in.
3. Fix things where they do not fit: columns, categories, special characters.
4. Take over the rest.
5. Work in parallel, for one to two weeks. New things are maintained in the new system; the old one remains available read-only.
6. Switch off the old accounts — only now. Otherwise two people maintain two systems, and neither is right any more.

The most common mistake is skipping step 2. Reading in a list of 4,000 contacts wrongly takes just as long as fifty — only the tidying up then takes days.

Enlarge

Four questions that become expensive afterwards if nobody asked them beforehand:

• Who owns the data in the old system? With a hosted service, you often cannot get at it any more after cancelling. Export while the contract is still running.
• What is really needed? A contact list that has been growing for eight years contains dead records, duplicates and addresses of people who have long since moved on. The switch is the best moment not to take that with you.
• Who may see what? Roles in the old system are rarely the same as here. Decide beforehand who becomes administrator — not during the first week of live operation.
• When is the cut-off date? Without a date, parallel operation becomes a permanent state.

And a fifth that is often forgotten: who has the credentials for the domain? Without them, you can neither set up deliverability nor move a website.

Via the import under Contacts. Aurora Hive Sales reads Excel files (.xlsx, .xlsm) and CSV; it recognises by itself which column is which field from the headings and, where these give nothing away, from the values.

What you should do beforehand:

• Delete everything above the column names — logos, headings, merged cells. The first row must contain the column names.
• One row per person, not one per company with five names in one cell.
• Combine notes. Five comment columns become one notes field in Aurora Hive Sales; decide beforehand what belongs in it.

Before importing, the dry run shows you what will happen — how many will be newly created, how many added to and how many recognised as duplicates.

Yes — by way of a file. Outlook exports contacts as CSV; Aurora Hive Sales reads that file.

In Outlook: File → Open & Export → Import/Export → Export to a file → Comma Separated Values. Then the usual preparation: first row with column names, delete superfluous columns.

Two things you should know:

• Outlook exports a great many columns (over eighty). Delete what you do not need — otherwise you spend a long time during the import mapping fields you never look at.
• A distribution list is not a contact and does not come across. In Aurora Hive Sales, distribution lists become categories; you assign them after the import.

There is no ongoing synchronisation with Outlook. The mailbox is connected, the address book is not — contacts should be maintained in one place, otherwise the wrong one always wins.

No, and that is a deliberate decision. A direct connection to a third-party system has to be maintained as soon as something changes there, and it tempts you to take over the old data stock without checking it.

The route is via export: every serious CRM can output contacts and companies as CSV or Excel. You read that file in here.

What does not come across:

• The history. Who discussed what with whom and when is stored in someone else’s data model and cannot be mapped sensibly. Keep the old system open read-only for a while.
• Links between records that do not exist here.
• Attachments that were attached to the record.

What you can do instead: write the most important notes for each contact into a “Notes” column and import them too. That is manual work, but it is the manual work that pays off — nobody reads anything else any more anyway.

Two routes, and together they give a usable result:

• Read in from the address. Aurora Hive Sites opens your site, looks for the sitemap and reads up to 40 pages from it. From each page, the heading, text and images are translated into blocks; the images go into your media library. If there is no sitemap, only the home page is read.
• The blog separately. WIX exports blog posts as CSV. You upload the file; each post is created as a draft, with title, text, summary and the images.

What this means: content comes across, the look does not. You choose the theme afresh in Aurora Hive Sites — which is also the point, because rebuilding a WIX layout would bring along all the drawbacks you are switching to get away from.

Expect follow-up work: order of the blocks, image crops, navigation. The import saves typing, not designing.

For all four there is a route via the respective export file:

• WordPress — the WXR file (XML) from Tools → Export.
• Squarespace — exports the same format and is therefore read in the same way.
• Joomla (J2XML) and TYPO3 (impexp XML) — both work, but are expressly marked as beta. Check the result particularly carefully here.

In all cases the same applies as with WIX: texts, posts and images come across, the look does not. Plugins, forms and anything generated by extensions on a WordPress site do not come across either — you rebuild the corresponding functions in Aurora Hive Sites, where they exist.

What you must check yourself in every case: the addresses of the pages. If a subpage was previously reachable at a particular address, it should be again afterwards — otherwise you lose your rankings in search engines.

This is the point at which a move can go measurably wrong. If your-company.com/services leads nowhere after the move, you lose not only the visitor but also the ranking that this page has earned on Google.

So: make a list of your page addresses before the move. The sitemap of your old site is the easiest way to do this — it is almost always at your-domain/sitemap.xml.

Then decide for each address:

• Keep it the same. The best solution. Create the new page under the same address.
• Redirect. If the structure changes, a redirect leads from old to new.
• Drop it. Only for pages nobody visited anyway.

You recognise the pages that matter by two things: they are near the top of your visitor statistics, and other websites link to them.

Allow half a day to a whole day for a typical company site with five to ten pages — and more if the old site has grown over years.

What regularly comes up:

• Order and layout of the blocks. The import guesses what is a heading and what is body text. It is usually right, not always.
• Image crops. An image that looked good in the old layout is cropped differently in the new one.
• Navigation. You decide afresh which page belongs where.
• Legal texts. Better not take over the legal notice (Impressum) and privacy notice but have them generated anew — the old ones match the old technology.
• Forms. Never come across and are created anew.

What the import saves you is the typing and uploading of the images. That is more than it sounds: it is the part where mistakes happen.

Yes. Member management reads in a file, just like Contacts — with names, addresses and the details you include.

More important here than the how is the what: do not take everything with you.

• Bank details only belong where they are needed. If you continue to handle direct debits via your club software or the bank, IBANs have no business being here.
• Details of health, ethnic origin or religion are specially protected. They turn up in membership lists surprisingly often — as a comment, as an abbreviation, as a column called “Special notes”. Leave them out if you cannot say what you need them for.
• Former members do not belong in the active list. What you have to keep for tax reasons, keep separately.

The switch is the only occasion on which something like this can be sorted out without discussion. Later someone will ask: “Why is that in there?”

As briefly as possible, as long as necessary — and in practice that means one to two weeks for day-to-day work, one to two years for read-only access.

The difference matters:

• Working in parallel means maintaining data in two places. That is expensive, error-prone and must not become the norm. Set a date from which new things are only created here.
• Keeping in parallel means the old system sits idle and can be read. That costs almost nothing and saves you when, after four months, someone asks what was discussed with a customer in 2023.

If the old system costs money while it is running, export everything into an archive instead — a collection of files on a drive that is backed up. Not pretty, but sufficient, and it costs nothing.

By four things, all of which should be met:

1. Two weeks without going back. Nobody has opened the old system to look something up.
2. A full cycle has passed. With monthly invoicing, that means one month end. Much only comes to light when the first monthly run is due.
3. The export is available — not as a declaration of intent, but as a file that someone has opened and looked at.
4. The credentials are documented. Anyone who discovers after cancelling that only a colleague who has left had the access will not be able to get at anything any more.

And then: only cancel once the export has been checked. With many services, access ends with the contract, not after a period of grace.

The technical switch is rarely the problem. The problem is that a new system first looks like extra work to colleagues and only later like a relief.

What helps:

• Show one benefit first, not the whole system. Anyone who sees that the follow-up saves them an Excel list will ask about the rest by themselves.
• Name one person who knows how it works. Not as a responsibility, but as a point of contact. Otherwise everyone asks you.
• Use the demo films. Every area has one; together with the tour, this replaces training for most tasks.
• Do not activate all modules at once. An interface with twenty entries in the sidebar is off-putting. Hide what is not needed yet.

What does not help: a two-hour training session for everyone on the same day. What sticks afterwards is the impression that it is complicated.

Before, and roughly, not finely.

Roughly means: whatever can obviously go does not come across in the first place. Contacts without an email address and without a phone number. Companies that no longer exist. Records nobody has touched for eight years. You do not need a tool for that, just a filter in Excel and half an hour.

Finely means: standardising spellings, merging duplicates, organising categories. You do that afterwards, because the tools here help you with it — duplicate detection during import and merging in the existing data.

The reason for this order: rough sorting out saves time during the move. Fine tidying before the move is work you do twice.

Then you switch back, and you should know beforehand that this is possible, not find out afterwards.

You can get at your data at any time:

• Contacts, companies, opportunities can be output as a file.
• A website can be exported as finished HTML and then runs on any web space.
• Documents and attachments are available as files.

What does not come across is the context: which email belonged to which campaign, which note was attached to which contact. That is the case with every change of system, in both directions.

The practical advice: keep the old export file for the first few weeks. As long as it is still there, the way back is a matter of hours, not days.

For a small business with a few hundred contacts and a website: two to three days of work spread over two to three weeks.

Divided roughly as follows:

• Half a day for the export from the old system and tidying up the file.
• One to two hours for the import itself, including the dry run.
• Half a day to a whole day for the website, if there is one.
• One to two hours for the setup: connect the mailbox, deliverability, user accounts, legal texts.
• The rest is spread over the first few weeks: organising categories, writing templates, small things.

What drags things out is almost never the technology. It is waiting for credentials — for the old website, the domain management, the email account. Take care of that first.

Yes. This makes sense above all in three places where a mistake becomes expensive:

• The domain and deliverability. A wrongly set record can mean that no email arrives for days — and nobody notices, because emails do not bounce back but are silently filtered out.
• The redirects of the old page addresses. Done right once, effective permanently.
• The first data import, if the source file is confusing.

Everything else — categories, templates, texts — you are better off doing yourself. Not to save money, but because you get to know the system in the process. Anyone who has written their templates themselves once changes them later in five minutes instead of in an email to the service provider.