Confluence server to cloud migration assistant stuck forever in "checking format of email address"
Asked by yogesh_devi:

Hello

I am using confluence server Confluence 7.13.2 and confluence cloud migration assistant Version: 3.3.2

I connect to confluence using a proxied URL

I take following steps from Migration Assistant home

3. MIGRATE YOUR DATA --\> Migrations dashboard --\> Create new migration --\> connect to cloud --\> Name your migration\* + Choose your destination cloud site\* --\> Choose what to migrate --\> select (spaces + users related to selected spaces + none apps ) - Then I choose the spaces to migrate using checkboxes --\>Click on Add to migration

At this juncture or earlier I start seeing pop ups "we cant communicate to your server:" and the "check for error" screen hangs forever with the items "checking format of email address" and "checking for duplicate ..." going round in circles .

See attached pictures below

![CantCOmmuToServer.png](/t5/image/serverpage/image-id/178219i03D3D4B8BE56CD14/image-size/large?v=v2&px=999 "CantCOmmuToServer.png")![CheckForErrors.png](/t5/image/serverpage/image-id/178220i8FD9B3D6ED2A4AA2/image-size/large?v=v2&px=999 "CheckForErrors.png")


Answers:
author: yogesh_devi
body: Since I am presently stuck _ I tried this workaround

I looked at <https://community.atlassian.com/t5/Confluence-questions/App-Migration-to-cloud-We-can-t-communicate-with-your-server/qaq-p/1825437>

And I tried [a dark feature in Confluence Server](https://developer.atlassian.com/platform/app-migration/testing/dev-mode/) to test my migration

<https://developer.atlassian.com/platform/app-migration/testing/dev-mode/>

As per that I enabled "migration-assistant.app-migration.dev-mode"

However even the Dev mode does not seem to help me

So based on discussions with [@Pramodh M](/t5/user/viewprofilepage/user-id/3691224) we figured the most likely cause to be that I am running confluence from behind a proxy and I ran the migration tool accessing confluence through a proxied URL .

So to eliminate that factor, I ran migration tool accessing Atlassian using a direct URL I made some headway .

While I continue to get message as follows I am able to create a migration  
++**So moral of the story --**++  
++**The migration assistant Version: 3.3.2 should be used from direct URL**++  
++**It Will not work behind a proxied URL**++

for more details, see discussion with [@Pramodh M](/t5/user/viewprofilepage/user-id/3691224) below

![CantCOmmuToServer.png](https://community.atlassian.com/t5/image/serverpage/image-id/178984i0F11C21FBB9B12DB/image-size/large?v=v2&px=999 "CantCOmmuToServer.png")

comments: author: Pramodh M
body: [@yogesh_devi](/t5/user/viewprofilepage/user-id/737128)

So basically in the end it depends on where the confluence is requesting the user data from

In this case crowd right?

Can you confirm you are accessing the instance via base URL and please use the base URL everywhere, add the URL to Crowd as well where we have an option to whitelist when making a connection.

Please check the settings with all the URLs set to same value. Atleast that should work

please check the logs in your instance for progress, also it may takes long time when we have more number of users.

Thanks,

Pramodh


author: Pramodh M
body: [@yogesh_devi](/t5/user/viewprofilepage/user-id/737128)

Please let me know if the issue was addressed


author: yogesh_devi
body: Hi [@Pramodh M](/t5/user/viewprofilepage/user-id/3691224) - Our Confluence sits behind a proxy server ( proxy is a google load balancer) . Base URL uses domain name of proxy server and points to proxy server (which has a SSL cert for the URL with that domain name.) The proxy redirects to back end confluence server based on context (/confluence)

The confluence functionality has been working fine for years now with this proxied base URL.

What is your take given this fact ?

Would you suggest that I access confluence directly from the subnet where confluence sits - albeit that would be using confluence native URL using its IP address, which is NOT the base URL . Would that work in your opinion


author: Pramodh M
body: [@yogesh_devi](/t5/user/viewprofilepage/user-id/737128)

Will you try accessing Confluence instance directly, and while you access Confluence directly make sure to change the base URL to the IP of the server and try with migration


author: yogesh_devi
body: The problem with that is that the Base URL change will affect our users across the globe - It will mean confluence downtime from user perspective. Would you suggest that I clone confluence for sake of migration,

But quite honestly ; to me it seems like migration assistant is making assumptions that aren't in accordance with regular product behavior ; can you take this back to the team that develops or supports migration assistant ?


author: Pramodh M
body: [@yogesh_devi](/t5/user/viewprofilepage/user-id/737128)

Yeah we have observed delay when we have this kind of environment where the user and group checks will be delayed when you have different url managed apart from base URL

Can you atleast try everywhere keeping the base URL same and try the migration?


author: Pramodh M
body: Glad [@yogesh_devi](/t5/user/viewprofilepage/user-id/737128) !!

Thanks,  
Pramodh


author: yogesh_devi
body: Hi [@Pramodh M](/t5/user/viewprofilepage/user-id/3691224)

Yes with accessing the confluence from direct URL ( bypassing the proxy ) following happened

I continue to see "We cant communicate to your server"

However ignoring that message and also ignoring warnings owing to "incorrect base URL"

I could finally get to a blank "Check for errors" screen on which I see a "No blocking errors found" message and "review Migration " button enabled .

See below

So looks like I am past this stumbling block

![Atlassian-Confluence-Errors.png](https://community.atlassian.com/t5/image/serverpage/image-id/178991i66C136CBCD9813BA/image-size/large?v=v2&px=999 "Atlassian-Confluence-Errors.png")  
So moral of the story --  
The migration assistant Version: 3.3.2 should be used from direct URL  
It Will not work behind a proxied URL  
You have to use direct URL  
Thanks for all your help


author: James Richards
body: Hi,

Honestly it will work. But you have to make sure your proxy is set up completely correctly in order for the React components to work correctly.

Maybe start with <https://confluence.atlassian.com/doc/proxy-and-https-setup-for-confluence-950286281.html> and work though the proxy.

Also, do you mean reverse proxy or a forward proxy?

James.


author: James Richards
body: Hi [@yogesh_devi](/t5/user/viewprofilepage/user-id/737128)

The error you're seeing is a very generic error that could be a number of things.

It's not related to using **dev-mode** for app migration since you aren't migrating apps, so you don't need the dark feature on, and it's likely to cause more problems than you want. Also, the bug referred to in <https://community.atlassian.com/t5/Confluence-questions/App-Migration-to-cloud-We-can-t-communicate-with-your-server/qaq-p/1825437> has been fixed, so **dev-mode** really is not needed.

It's not <https://jira.atlassian.com/browse/MIG-241> because that's related to Jira and site import.

What is happening in the log file? Look for \<confluence-home\>/logs/atlassian-confluence.log and see what's happening there.

When you run a migration, look for any lines with ERROR, or a Java stack trace. That's our starting point.

Also make sure you've gone though the [migration guide](https://www.atlassian.com/migration) to ensure everything is configured correctly.

Regards,  
James.


author: Pramodh M
body: Hi [@yogesh_devi](/t5/user/viewprofilepage/user-id/737128)

If you have connected the external directory with Confluence, be sure to perform a sync before you do the migration.

FYI, try this and let me know

<https://confluence.atlassian.com/cloudkb/how-to-fix-plans-that-are-stuck-and-cannot-be-stopped-during-migration-in-confluence-cloud-migration-assistant-ccma-1095245292.html>

Thanks,  
Pramodh

comments: author: Pramodh M
body: FYI

<https://jira.atlassian.com/browse/MIG-241>


author: yogesh_devi
body: Hi [@Pramodh M](/t5/user/viewprofilepage/user-id/3691224)

Thanks for your response.

Since confluence uses a crowd server as a user directory - that in turn connects to a active directory so based on your suggestion I first tried synchronizing Confluence with Crowd. And re-tried migration after the sync completed successfully .That did not help ( I get the same error)

Then I tried synchronizing Crowd with Active Directory Server and then synchronizing Confluence with Crowd. I thereafter re-tried migration after the sync completed successfully. That too did not help ( I again get the same error)

I did ensure that no migration plan is already running

mysql\> select \* from scheduler_clustered_jobs where job_runner_key like '%migration%';  
Empty set (0.03 sec)

I also noticed that none of the migration task related tables are created

mysql\> select \* from mig_work_item;  
ERROR 1146 (42S02): Table 'confluence.mig_work_item' doesn't exist  
mysql\> select \* from mig_task where executionstatus = 'RUNNING'  
-\> ;  
ERROR 1146 (42S02): Table 'confluence.mig_task' doesn't exist

So which means the migrations are NOT getting started at all owing to whatever reason that is showing up as this error


Tags: confluence-server

migration-customer-care

server