Confluence server to cloud migration assistant stuck forever in "checking format of email address"

[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 

[yogesh_devi · Accepted solution]

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 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   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  below  

[Pramodh M]

@yogesh_devi 

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

[Pramodh M]

@yogesh_devi 

Please let me know if the issue was addressed

[yogesh_devi]

Hi @Pramodh M  - 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 

[Pramodh M]

@yogesh_devi 

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

[yogesh_devi]

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 ?

[Pramodh M]

@yogesh_devi 

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?

[Pramodh M]

Glad @yogesh_devi !!

Thanks,
Pramodh

[yogesh_devi]

Hi @Pramodh M 

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

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 

[James Richards]

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.

[James Richards]

Hi @yogesh_devi

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 to ensure everything is configured correctly.

Regards,
James.

[Pramodh M]

Hi @yogesh_devi

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

[Pramodh M]

FYI

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

[yogesh_devi]

Hi @Pramodh M 

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