Email migration is a critical task when moving hosting providers or consolidating accounts. One of the most reliable and secure tools for this process is imapsync, which allows you to synchronize emails between two IMAP servers without data loss.

In this guide, we’ll walk through a practical, production-ready method using Docker, making the process clean, repeatable, and server-safe.

This guide is prepared for implementation use cases handled by African Script, especially for clients migrating cPanel-based email systems.

What is imapsync?

imapsync is an open-source command-line tool used to synchronize emails between two IMAP servers. It is widely used for:

• cPanel to cPanel migrations
• Gmail to cPanel migrations
• Backup and replication of mailboxes
• Hosting transfers without downtime

It ensures emails, folders, flags, and metadata are preserved.

Why Use Docker for imapsync?

Using Docker simplifies installation because:

• No dependency conflicts
• Works on any Linux server
• No need to compile imapsync manually
• Easy repeatable execution

Step 1: Install Docker

On your Linux server (Ubuntu/Debian):

sudo apt update
sudo apt install -y docker.io
sudo systemctl enable docker
sudo systemctl start docker

Verify installation:

docker --version

Step 2: Pull imapsync Docker Image

We will use a ready-made image:

docker pull gilleslamiral/imapsync

This image contains everything needed to run imapsync immediately.

Step 3: Prepare Your cPanel Email Details

You need the following for both source and destination:

Source (Old cPanel)

• IMAP server (e.g. mail.old-domain.com)
• Email address
• Password
• Port (usually 993 for SSL)

Destination (New cPanel)

• IMAP server (e.g. mail.new-domain.com)
• Email address
• Password
• Port (993 SSL)

Step 4: Run imapsync via Docker

Execute the migration command:

docker run --rm gilleslamiral/imapsync \
--host1 mail.old-domain.com \
--user1 user@olddomain.com \
--password1 'OLD_PASSWORD' \
--ssl1 \
--host2 mail.new-domain.com \
--user2 user@newdomain.com \
--password2 'NEW_PASSWORD' \
--ssl2

Step 5: Understanding the Command

• host1 → Source mail server
• user1 → Source email
• password1 → Source password
• host2 → Destination mail server
• user2 → Destination email
• ssl1 / ssl2 → Enables secure SSL connection
• --rm → Removes container after completion

Step 6: Optional Advanced Flags (Recommended)

For production migrations, use:

Skip already migrated emails

--automap

Keep all flags and read states

--syncinternaldates

Dry run (test before actual migration)

--dry

Example:

docker run --rm gilleslamiral/imapsync \
--host1 mail.old-domain.com \
--user1 user@olddomain.com \
--password1 'OLD_PASSWORD' \
--ssl1 \
--host2 mail.new-domain.com \
--user2 user@newdomain.com \
--password2 'NEW_PASSWORD' \
--ssl2 \
--automap \
--syncinternaldates

Step 7: Verify Migration

After completion:

• Log into new cPanel webmail
• Check folder structure
• Confirm email counts match
• Spot-check recent and old emails

Common Issues & Fixes

1. Authentication Failed

• Confirm password correctness
• Check IMAP is enabled in cPanel

2. Connection Timeout

• Verify port 993 is open
• Check firewall rules

3. Missing Emails

• Re-run imapsync (it is safe; it skips duplicates)

Why This Approach is Ideal for Agencies

For agencies like African Script, this method is ideal because:

• Fully automated migration workflow
• No reliance on cPanel backups
• Works across different hosting providers
• Scales for multiple clients
• Minimizes downtime risk

Using imapsync with Docker is one of the most efficient and professional ways to migrate email accounts between cPanel servers. It ensures reliability, security, and full data integrity without manual export/import risks.

For agencies handling multiple migrations, this method becomes a repeatable operational standard.



Losing databases unexpectedly can feel catastrophic — especially when it happens after installing something that’s supposed to help, not break things. That’s what happened when I installed MariaDB while setting up Daloradius on my Ubuntu system.

After installation, all my databases were gone, and phpMyAdmin started showing this dreaded message:

mysqli::real_connect(): (HY000/1698): Access denied for user 'phpmyadmin'@'localhost'

When I logged into the database, all my previous projects had vanished. But I eventually managed to recover everything manually — without using sudo timeshift --restore. Here’s how I did it step by step.

1. Understanding the Problem

When you install MariaDB on a system that already has MySQL, Ubuntu often treats MariaDB as a drop-in replacement for MySQL.

That means:

• MySQL is automatically removed or replaced.

• The folder /var/lib/mysql (which contains all databases) is overwritten with a fresh MariaDB data directory.

• Your old database files are not deleted from disk immediately — but they’re moved, renamed, or left behind in a previous snapshot folder (if you use Timeshift or have manual backups).

As a result, logging into phpMyAdmin or MySQL shows no user-created databases.

2. Verifying That MariaDB Overwrote MySQL

To confirm that MySQL was replaced:

mysql --version

It returned something like

mysql Ver 15.1 Distrib 10.x.x-MariaDB, for Linux (x86_64)


That meant MySQL binaries were now replaced by MariaDB. Checking databases:

sudo mariadb -u root -p

SHOW DATABASES;

Only system databases like mysql, information_schema, and performance_schema appeared — everything else was gone.

3. Removing MariaDB Completely

To restore my system, I decided to remove MariaDB entirely.

sudo systemctl stop mariadb
sudo apt purge mariadb-server mariadb-client mariadb-common -y
sudo apt autoremove -y
sudo apt autoclean

Then, I verified that no MariaDB packages were still on the system:

dpkg -l | grep mariadb

If any showed up, I manually removed them too.

4. Reinstalling MySQL

Once MariaDB was gone, I reinstalled MySQL 8.0:

sudo apt update
sudo apt install mysql-server -y

There were a few configuration prompts and minor errors like:

update-alternatives: error: alternative path /etc/mysql/mysql.cnf doesn't exist

I simply chose the default options (pressing Enter where prompted). After installation, MySQL was back, but with a fresh data directory — and, of course, no old databases.

5. Manually Restoring the Old Databases

Here’s where the manual recovery came in.

Step 1: Locate the old MySQL folder

I opened my Timeshift snapshots manually (without running restore).
Timeshift stores snapshots under:

/timeshift/snapshots/

Inside the latest snapshot folder, I navigated to:

/timeshift/snapshots/<snapshot-date>/localhost/var/lib/


Here, I found my old MySQL folder that contained all my previous .frm, .ibd, .ibdata1, and .myd database files.

Step 2: Stop the MySQL service

Before replacing anything, I stopped MySQL:

sudo systemctl stop mysql

Step 3: Backup the new (empty) MySQL folder

Just to be safe:

sudo mv /var/lib/mysql /var/lib/mysql_backup_new

Step 4: Copy the old MySQL folder from the snapshot

Then I copied my old databases back:

sudo cp -r /timeshift/snapshots/<snapshot-date>/localhost/var/lib/mysql /var/lib/mysql

(Replace <snapshot-date> with the correct snapshot folder name.)

Step 5: Set proper ownership and permissions

sudo chown -R mysql:mysql /var/lib/mysql

sudo chmod -R 755 /var/lib/mysql

Step 6: Restart MySQL

sudo systemctl start mysql

If everything went fine, the MySQL service started normally.

6. Confirming the Recovery

Once MySQL was running again, I logged in:

sudo mysql -u root -p

Then checked all databases:

SHOW DATABASES;

To my relief, all my previous databases were back exactly as they were before the MariaDB installation.

phpMyAdmin also loaded perfectly again, without the “access denied” errors.

7. Backing Up Everything Immediately

The first thing I did after recovery was back up all databases to a single .sql file:

mysqldump -u root -p --all-databases > ~/backup_all_databases.sql

That way, even if something similar happens again, I can restore everything with one command:

mysql -u root -p < ~/backup_all_databases.sql

8. Key Takeaways

• MariaDB and MySQL share the same paths — installing one can silently replace the other.
• Your old data isn’t necessarily gone — it’s just no longer linked to the running service.
• Manual restoration works if you can access old system files via Timeshift or a backup.
• Always stop the MySQL service before overwriting /var/lib/mysql, and fix file permissions afterward.
• Keep regular SQL dumps to make recovery faster next time.

This experience was a reminder that even routine installations can wipe out critical data if we’re not careful.
By manually restoring the /var/lib/mysql directory from a snapshot and resetting file permissions, I managed to recover every single database without using full system restore tools.

So, if you ever find yourself staring at an empty phpMyAdmin after a MariaDB install — don’t panic.
Your data is probably still there. You just need to bring it home.

How to Choose the Right Software Development Partner

Choosing a software development partner is like picking a co-pilot for a long journey. The right one ensures a smooth ride; the wrong one can leave you stranded.

Many businesses—especially startups and SMEs—struggle with this decision. Should you hire locally or outsource? How do you know if a developer is truly skilled or just good at selling themselves? And what about hidden costs, missed deadlines, or security risks?

In this guide, we’ll break down:
✅ Key factors to evaluate (beyond just cost)
🚩 Red flags that signal trouble
💡 Real-world tips from industry experts

By the end, you’ll know exactly what to look for—and how to avoid costly mistakes.

Step 1: Define Your Needs Clearly

Before searching for a partner, ask:

• What problem are you solving? (A new app, legacy system upgrade, AI integration?)
• What’s your budget and timeline? (Fixed cost? Agile development?)
• Do you need ongoing support? (Or just a one-time build?)

Example:
A fintech startup needing a secure mobile payment app will prioritize:
✔ Regulatory compliance (PCI-DSS, GDPR)
✔ Experienced fintech developers
✔ Post-launch maintenance

A small business wanting a basic website may focus more on:
✔ Affordable, fast delivery
✔ User-friendly CMS (like WordPress)

Pro Tip: Write a short project brief (even 1 page helps) to share with potential partners.

Step 2: Look for Technical Expertise

A. Relevant Experience

• Have they built similar projects before? Ask for case studies or demos.
• Do they understand your industry’s challenges? (E.g., healthcare needs HIPAA compliance.)

Warning Sign:
❌ "We can build anything!" (Without proof.)

B. Tech Stack Knowledge

• Do they use modern, scalable technologies? (Avoid partners stuck in outdated systems.)
• Can they explain why they chose a certain tech? (Not just following trends.)

Example:

• Web apps: React.js (frontend) + Node.js (backend)
• Mobile apps: Flutter (cross-platform) or Swift/Kotlin (native)
• AI/ML: Python, TensorFlow

Pro Tip: Ask: "How would you architect this project?" Their answer reveals depth of knowledge.

Step 3: Evaluate Communication & Transparency

Poor communication causes 60% of project failures (PMI). Look for:

✔ Clear processes (Daily standups? Weekly reports?)
✔ Timezone overlap (At least 4 hours for real-time collaboration.)
✔ Single point of contact (Avoid getting passed between 5 people.)

Red Flags:
❌ Slow email responses (24+ hours regularly)
❌ Vague answers to technical questions

Pro Tip: Do a trial task (paid) to test responsiveness before committing.

Step 4: Check Security & Compliance

A single data breach costs $4.45 million on average (IBM). Ensure your partner:

✔ Follows secure coding practices (OWASP standards)
✔ Signs an NDA & data protection agreement
✔ Has disaster recovery plans (Ask: "How do you handle breaches?")

Critical for:

• Healthcare (HIPAA)
• Finance (PCI-DSS, SOC 2)
• EU clients (GDPR)

Step 5: Compare Pricing Models

Ask:

• "What’s included in the cost?" (Hidden fees for support?)
• "How do you handle scope changes?"

Step 6: Verify Reputation

✅ Clutch.co/G2 reviews (Look for detailed feedback.)
✅ Ask for client references (Talk to past clients directly.)
✅ GitHub/Portfolio (Check code quality if possible.)

Red Flag:
❌ No portfolio or only "testimonials" from unverifiable sources.

Final Checklist Before Signing

🔲 Defined project scope & milestones
🔲 Clear contract (IP ownership, support terms)
🔲 Security protocols in place
🔲 Trial period or pilot project

Need a Reliable Partner? Try Africancscript

We’ve helped 150+ businesses build secure, scalable software with:
✔ Vetted developers in Africa (Cost-efficient, high-quality)
✔ End-to-end project ownership (From idea to launch)
✔ Transparent Agile processes (No surprise delays)

[Book a Free Consultation] → Let’s discuss your project!