Just experienced this issue today. Note that there was also a crash of kded, which might have caused the issue. With all that said, this "akonadi_migration_agent" popup usually shows on every login and goes away after about 2-3 seconds.

I still have this. October 2024.
At first glance I would ask: why isn't there the possibility to "never show again" or something like that, but still, that would be asking the wrong question.
The right question would rather be: who at all would like to be notified about this? In what way is the fact that the akonadi_migration_agent completed it's task important to me???

(In reply to PK from comment #2)
> I still have this. October 2024.
> At first glance I would ask: why isn't there the possibility to "never show
> again" or something like that, but still, that would be asking the wrong
> question.
> The right question would rather be: who at all would like to be notified
> about this? In what way is the fact that the akonadi_migration_agent
> completed it's task important to me???

I found the only "fix" for this is to get rid of all things KDE. The Akondi database has been a tragedy from the beginning. I've been in it roughly 40 yeas now and started with SuSE when it came in two boxes: one with floppies, the other with printed documentation.

I installed NextCloud on an old i7 gen4 or gen6 in my office.
https://nextcloud.com/
I installed BetterBird on my machines.
https://www.betterbird.eu/

Also installed a 16TB NAS (which doesn't sound as big as it used to).

Now, Manjaro, Windows 10, Linux Mint, openSuSE Leap, all share the same documents, contacts, etc. None of them run any KDE packages and none have this problem.

I am observing this issue regularly after updates to KDE Plasma packages on Arch Linux. On next reboot, SDDM typically takes much longer than usual to show up. After successful login, I observe a black screen with blinking cursor. If I wait long enough, finally the KDE Plasma desktop will show up with the akonadi_migration_agent "In progress" dialogue spinning. With that dialogue active, KDE Plasma seems to have also trouble to cleanly logout the session, shutdown, or reboot the computer. If one tries to work in that session, I observed freezes of applications after a short time, which normally run without issues, namely Firefox, Thunderbird, and Libreoffice.

In the past rebooting typically helped to make the issue go away until the next update of KDE Plasma packages. However today, the issue would persist even after several reboots. Only removing ~/.cache in a console session before logging in via SDDM into KDE Plasma (Wayland session) helped. KDE Plasma is at version 6.3.2 currently on Arch Linux.

(In reply to Torsten Maehne from comment #4)
> I am observing this issue regularly after updates to KDE Plasma packages on
> Arch Linux. On next reboot, SDDM typically takes much longer than usual to
> show up. After successful login, I observe a black screen with blinking
> cursor. If I wait long enough, finally the KDE Plasma desktop will show up
> with the akonadi_migration_agent "In progress" dialogue spinning. With that
> dialogue active, KDE Plasma seems to have also trouble to cleanly logout the
> session, shutdown, or reboot the computer. If one tries to work in that
> session, I observed freezes of applications after a short time, which
> normally run without issues, namely Firefox, Thunderbird, and Libreoffice.
> 
> In the past rebooting typically helped to make the issue go away until the
> next update of KDE Plasma packages. However today, the issue would persist
> even after several reboots. Only removing ~/.cache in a console session
> before logging in via SDDM into KDE Plasma (Wayland session) helped. KDE
> Plasma is at version 6.3.2 currently on Arch Linux.

Having come up on real computers with real operating systems where actual Software Engineering (not Agile) and physical QA teams (not TDD) were used, I am always mortified at the roughly 99% of PC applications that can't bother to clear their disk cache on startup. Adding insult to injury, the format of the files changes between updates, new software is never tested with the old cache format and doesn't check for it, then all sorts of gastric intestinal application issues happen after an update is pushed out.

If the software development process can't be fixed, at least fix the update process so it closes the application and nukes the cache before applying the update.

Cache is meant only for the current running instance, not for saving settings between runs.

It started happening on my Fedora KDE installation after the recent update. It is just stuck forever.

Operating System: Fedora Linux 41
KDE Plasma Version: 6.3.2
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
Kernel Version: 6.13.5-200.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: AMD Radeon RX 6700 XT
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7D52
System Version: 1.0

(In reply to roland from comment #5)
> (In reply to Torsten Maehne from comment #4)
> > I am observing this issue regularly after updates to KDE Plasma packages on
> > Arch Linux. On next reboot, SDDM typically takes much longer than usual to
> > show up. After successful login, I observe a black screen with blinking
> > cursor. If I wait long enough, finally the KDE Plasma desktop will show up
> > with the akonadi_migration_agent "In progress" dialogue spinning. With that
> > dialogue active, KDE Plasma seems to have also trouble to cleanly logout the
> > session, shutdown, or reboot the computer. If one tries to work in that
> > session, I observed freezes of applications after a short time, which
> > normally run without issues, namely Firefox, Thunderbird, and Libreoffice.
> > 
> > In the past rebooting typically helped to make the issue go away until the
> > next update of KDE Plasma packages. However today, the issue would persist
> > even after several reboots. Only removing ~/.cache in a console session
> > before logging in via SDDM into KDE Plasma (Wayland session) helped. KDE
> > Plasma is at version 6.3.2 currently on Arch Linux.
> 
> Having come up on real computers with real operating systems where actual
> Software Engineering (not Agile) and physical QA teams (not TDD) were used,
> I am always mortified at the roughly 99% of PC applications that can't
> bother to clear their disk cache on startup. Adding insult to injury, the
> format of the files changes between updates, new software is never tested
> with the old cache format and doesn't check for it, then all sorts of
> gastric intestinal application issues happen after an update is pushed out.
> 
> If the software development process can't be fixed, at least fix the update
> process so it closes the application and nukes the cache before applying the
> update.
> 
> Cache is meant only for the current running instance, not for saving
> settings between runs.

Deleting everything in ~/.cache works for me

(In reply to Clodoaldo from comment #7)
> (In reply to roland from comment #5)
> > (In reply to Torsten Maehne from comment #4)
> > .........
> > If the software development process can't be fixed, at least fix the update
> > process so it closes the application and nukes the cache before applying the
> > update.
> > 
> > Cache is meant only for the current running instance, not for saving
> > settings between runs.
> 
> Deleting everything in ~/.cache works for me

Thanks for the hint guys, deleting everything in ~/.cache and rebooting solved it.

But sorry, that can't be the solution, and the "Keywords: usability" above is an excessive undercutting.
My Fedora 42 KDE was almost completely unresponsive, so i had to look for a solution on my other PC, and was hardly able to open the terminal to run these simple commands which usually don't even take a second - imagine how many new Linux-users, which don't have a 2nd device just switch it off forever and go back to windows or proceed to MacOS.

I fully agree with  roland@logikalsolutions.com : Just 'nuke' the cache!

Just in case it's helpful: this never happend with Tuxedo OS which i used for ~1 year on my 2nd device.

(In reply to Thomas from comment #8)
> (In reply to Clodoaldo from comment #7)
> > (In reply to roland from comment #5)
> > > (In reply to Torsten Maehne from comment #4)
> > > .........
> > > If the software development process can't be fixed, at least fix the update
> > > process so it closes the application and nukes the cache before applying the
> > > update.
> > > 
> > > Cache is meant only for the current running instance, not for saving
> > > settings between runs.
> > 
> > Deleting everything in ~/.cache works for me
> 
> Thanks for the hint guys, deleting everything in ~/.cache and rebooting
> solved it.
> 
> But sorry, that can't be the solution, and the "Keywords: usability" above
> is an excessive undercutting.
> My Fedora 42 KDE was almost completely unresponsive, so i had to look for a
> solution on my other PC, and was hardly able to open the terminal to run
> these simple commands which usually don't even take a second - imagine how
> many new Linux-users, which don't have a 2nd device just switch it off
> forever and go back to windows or proceed to MacOS.
> 
> I fully agree with  roland@logikalsolutions.com : Just 'nuke' the cache!
> 
> Just in case it's helpful: this never happend with Tuxedo OS which i used
> for ~1 year on my 2nd device.

Most likely Tuxedo "maintainer" or their update system implemented the "nuke cache" policy.

Most "maintainers" of packages in other distros just put the name on their resume and hold their breath the up-stream version will always build automatically. On a very rare occasion they will fix a compilation error.

While many Linux installs have a single user on a single computer, there is the technical complication of having to nuke ~/.cache for all users. Definitely doable as part of the POST-INST step for .deb and .rpm. Other package managers . . . ???

I ran into this issue a few weeks ago on Arch but ignored it at first because it was just an annoying notification that could be dismissed. However, when I finally wanted to resolve the problem, I tried deleting everything in ~/.cache, which didn’t help.

I noticed that several KDE applications (for example, KOrganizer) were not functioning properly and were producing PIM‑related errors. When I examined my logs, I found entries such as:

Job error "" for collection: QList() on org.kde.pim.akonadicore
This made me suspect that the problem was not with the migration agent itself.

I then decided to delete all Akonadi–related files in both ~/.config and ~/.local/share/akonadi, and rebooted the system. This finally solved the issue for me.

It isn’t a clean solution (since I removed all databases and configuration files) but because I don’t use any of the applications built on Akonadi, it didn’t matter to me. It may serve as a workaround for others encountering the same problem. I’ll keep backups of the deleted data for a while in case I inadvertently broke something else that I haven’t noticed yet.

I have the same issue on Arch Linux with PostgreSQL 18.
Clean Akonadi install and the dialog still never goes away.

Almost same issue here (actually more similar to the more-recently reported bug 501434), but I wanted to share the (temporary?) solution I found elsewhere since it hasn't been posted here yet:

Create file ~/.config/akonadi/mysql-local.conf with contents:
[mysqld]
innodb_log_buffer_size=2M

One-liner:
echo -e '[mysqld]\ninnodb_log_buffer_size=2m' >~/.config/akonadi/mysql-local.conf

Credit to s2kfred at https://old.reddit.com/r/Fedora/comments/1ek18hw/akonadi_migration_agent_process_wont_end_how_to/

Hi,

forgive the daft question but does the reply above me work on a raspberry pi 5 please?
I noticed the first post has much better hardware than I do and also my kde is different version
but same problem

migration agent 

in progress 66% (sticks there for ever driving me nuts!)

KDE plasma version 6.4.4
KDE Frameworks 6.18.0
Kernel 6.12.28

I dont know what to use to create those files as suggested above me or where to put them, I bought a pi just to go on the internet and as a low powered device

(In reply to d-koc from comment #12)
> Almost same issue here (actually more similar to the more-recently reported
> bug 501434), but I wanted to share the (temporary?) solution I found
> elsewhere since it hasn't been posted here yet:
> 
> Create file ~/.config/akonadi/mysql-local.conf with contents:
> [mysqld]
> innodb_log_buffer_size=2M
> 
> One-liner:
> echo -e '[mysqld]\ninnodb_log_buffer_size=2m'
> >~/.config/akonadi/mysql-local.conf
> 
> Credit to s2kfred at
> https://old.reddit.com/r/Fedora/comments/1ek18hw/
> akonadi_migration_agent_process_wont_end_how_to/

Update: Doing this has NOT fixed the issue for me. However, I also cannot reproduce it consistently. It may still be worth trying on your system to see if it works.

I have not tried clearing the entire cache; I would prefer to find a consistent repro to attempt to fix the issue in a less extreme fashion.

> I dont know what to use to create those files as suggested above me or where to put them, I bought a pi just to go on the internet and as a low powered device

The 'echo [...]' command is a Unix/Linux (Bourne) shell command; you would generally enter it into a text-based (pseudo)terminal. iirc raspi OS has a Ctrl+Alt+T shortcut to access its default terminal application, but you should really avoid running commands you find on the internet until you understand the terminal (and your shell, e.g. sh, dash, bash, zsh, etc.) well enough to know what they do.

If you want to try creating the file anyway, you can use your default file manager, turn on "show hidden files" or whatever it's called on your file manager, and navigate to '/home/<your username>/.config/akonadi' and create a plain text file there with the contents

[mysqld]
innodb_log_buffer_size=2M

and nothing else.

> and create a plain text file there
Which of course needs to be named 'mysql-local.conf'