I have a migration that never fully completes, stalls at post-deployment step

I have a migration that is not very large but stalls at the post-deployment steps phase. The files remained closed and I’m not sure how to complete the migration. Can I just open the migrated files?
The migration should take about 20 minutes.

BTW, I also can’t get back to the Dashboard in the OttoFMS app interface. It’s like OttoFMS is hung. I tried to get to the app on another computer and the OttoFMS login screen never appears.

It does sounds like OttoFMS is hung up.

You might need to restart it.

And you can just open the files.

But I’d like to know whats happening here.

Can you send us the otto-info.log from that computer?



OK, I restarted the OttoFMS service on the Windows server ( 2019 Datacenter, version 1809). The migrated file closed and opened correctly and everything looks good.

You’ll notice from the log that this also happened three times on 4/29/2024 when I had to restart the OttoFMS service, but I just ended up using the old version of Otto to migrate. I thought the issue was a problem with one of the files I was migrating, so I tried different combinations.
During May I’ve had better luck, except for today. Hopefully, we can figure out what the issue is so I can use OttoFMS full-time.
I can’t seem to attach the log file to this message. I’ll try sending it in a DM.


Todd, we tried to do a migration again today and OttoFMS froze again. At least it is consistent now. Do you need an updated otttt-info.log file?


Sure you can send it along. Unfortunately the last time we looked at it showed nothing that I thought might be a clue. Maybe this time we’ll get lucky.

Do other deployments work?
Is it just a particular set of files?


I’ve tried combinations of files to see if one or more was the culprit but I couldn’t find one. I’ll try a few more tests to see if there is a pattern somewhere else.


Can you confirm that NO deployments work? IE every single file you try, even a simple empty file fails?

That would be good to know


Ok ya… what version of FileMaker server?


The server is running FMS 20.3.2 and I’m running OttoFMS 4.3.5. I think I found a file that seems to make a migration not complete. The file is called Eyebank. I did a few migrations with and without this file, maybe the log file will show something now. The last attempt was just to migrate Eyebank itself and it never got past the fetching step.
otto-logs.zip (25.6 KB)

Hi Tom,

hmm. I looked in the logs. Still not making any sense.

Could you send the deployment results from the one that worked and the one that didin’t?

see the image for how to download them


Here you go,
Results.zip (2.9 KB)

So sorry I wasn’t specific enough.

The logs are what we are really after.

Originally I wanted to use the Both (ZIP) option, but when I selected this option I got a “Download Error, Failed to fetch” message. For bot deployments.
Here are the logs from our Temp server, which is where I’ve been doing my recent tests.
logs.zip (2.6 KB)

And FYI, here are log files for the same files but deployed to different servers. The staging server was successful, but the temp server was not.
SameFilesDifferentServers.zip (3.9 KB)

Forgot to mention, both servers are running FMS 20.3.2

Hey Tom,

How big is your Temp server?

does it meet the minimum requirements


OK, I reviewed the OttoFMS system requirements. OttoFMS uses 2.5GB of RAM per file in the migration? I think that’s probably the issue. The temp server has 4 CPUs and 16GB of memory. When I was monitoring the server with the Resource Manager, the server is normally using about 10GB. So I’m running out of RAM when I try to migrate three files. OttoFMS starts but never comes back.

How does Otto’s memory usage compare to OttoFMS? I don’t have an issue migrating the same set of files between these servers with Otto?

I guess I just need to break up the migration into fewer files. My production server has 32GB of RAM so there is more room to work.

FYI, I also updated the temp server to FMS 21 last night and ran the same migration with the same results. But that should be expected.

OttoFMS’s memory usage should be the same as Otto v3. That is 2.5 GB of ram per file at a time. So if your concurrency is set to one it, it would only ever use 2.5 GB.

I don’t think you should be running out of memory, if you set the concurrency to three or less. But you could try setting it to 1.

Your server meets the minimum requirements. It should work ok with that setup. But clearly there is something different about that server.

Maybe it is running out of disk space. We do check that. So it shouldn’t let you get that far if you have no room. But it’s worth checking.


There is plenty of disk space on the server.
C: 256GB, 195G free
D: DB files, 512GB, 430G free
E: Backup, 800GB, 660G free

Earlier this week I had the same issue with our staging server. It has the same configuration as the temp server.

Otto V3 is working great on all the servers.
I already found out that I can’t set more than 1 for concurrency for these dev servers, it just takes too long. I set the concurrency to 2 for the production server which has twice the CPUs and twice the RAM and same disk configuration.