Migrate form Server to DC

[Yevhen Rohovets]

Hello to all

Could you describe the experience of migrating from a server to a data center for companies with more than 1000 people?

[Nic Brough -Adaptavist-]

Lots of planning, and a lot more testing, but actually quite smooth.

Main problem was the people losing non-DC compliant apps that they were using, the actual migration was smooth, in some places people didn't even know we'd done it because their new access was indistinguishable from the old - we had reports like "Oh, so it failed last night because nothing changed, right?"

I put that smoothness down to planning and preparation (read all of Atlassian's docs on it - there's some excellent advice in there.  Some of it you can skim and realise you don't need much of it, other parts you'll get a lot from)

[Yevhen Rohovets]

Thank for your answer, Nic.

I completely agree that you need to plan very clearly and prepare for the fact that in reality it may stop working

[Alyssa Warren]

Hi @Nic Brough -Adaptavist- ,

You mentioned that some of the Atlassian docs were helpful - do you remember any resources specifically that were most useful for customers moving from Server to DC? I work on the product marketing team here and am always curious to see which resources our customers need so we can make more of those types. 

Thanks,
Alyssa

[Nic Brough -Adaptavist-]

Nothing specific.  A "simple" Server -> DC is (technically) a doddle. 

It's the plugins and integrations that can break it, the Atlassian docs pretty much do "upgrade" and won't cause you problems now.

[Dave Rosenlund _Trundl_]

Hi, @Yevhen Rohovets.

It also happens that Atlassian is offering this webinar, where customers talk about their migration experience.  You may wish to attend.

-dave    

[Yevhen Rohovets]

Wow, nice, thank you!

[Lars Bachmann]

Hej @Yevhen Rohovets - the "migration" is not a big deal if all is planned well and in advance.

Where will you deploy DC - on AWS or Azure or On premise? We have a nice use case - global logistics company with over 30,000 employees with locations in US, Europe and Asia. Our Cloud Architects used AWS Cloudfront as a cache for static content. 
Directly behind the CDN, an AWS ELB (Elastic Load Balancer) is used, which receives the traffic and distributes it to the nodes via an AWS NAT gateway.

Well - i am NOT a Tech-Tech with AWS - So I don't guarantee the correctness of my statement. But i can connect you to the guys from the AWS unit if wanted. 

Best, Lars

[Yevhen Rohovets]

Thank you for your offer!

We are also AWS partners, so we can deploy the structure. My question is rather about what pitfalls were those who were already doing this.

[Boris Berenberg - Atlas Authority]

I think the biggest issues that we see are that teams deploy low quality networking, shared storage, and proxy configuration. The AWS CFTs will give you a good starting point to avoid these issues. But you also need to understand how this applies to your specific environment. Feel free to reach out if you need help. 

[brbojorque]

Another strategy is to create a staging instance first with the exact data from the previous instance, conduct a UAT per teams and then iterate over it.

Document critical business operations within the instance so it can be prioritized during the cut-over period.

As long as the server version is identical with the DC version the core functionalities don't differ much.

[Damian]

The only issue we have had (and continue to have) with moving from server to DC are the plugins/apps.

- The plugins/apps cost more now (since we are on a 500 user license instead of 250).

- Not all plugins are fully Data Center compatible. They may still work though.

- Data Center app updates sometimes come after the server version updates.

I'd suggest checking the version releases for each app you use on the Marketplace and see  what the company's release history of server/DC versions are. Are they released at the same time or is there normally a delay?

I have had one app that we use heavily that only releases their DC version well after the server version (e.g. last update was 5 months or so after the server version was released). This prevented us going to Jira 8.x. They released it finally, so I upgraded my Test environment only to find that another app that was listed as compatible didn't work in our Jira 8.2.4 Data Center (even though the upgrade checks said it would). It works in Server version though. That is certainly not the only time we've had issues like that. So we are staying on the Jira 7.13.x Enterprise releases for now.

The migration of Jira itself is a really easy/smooth process. It's simple to add another node to the cluster.

[Lars Bachmann]

I agree - it`s basically Apps Apps Apps :-) 

Also with licensing - you have to be careful not to lose too much money. Upgrading the apps is a new purchase. Especially for long license terms.