mediawiki to confluence migration

45
Switching to Confluence with 500+ Wiki users Migrating Bigpoint from Mediawiki to Confluence AUGHH user group meeting, 6.6.2012, Nils Hofmeister

Upload: nils-hofmeister

Post on 17-Nov-2014

909 views

Category:

Technology


8 download

DESCRIPTION

Presentation from Atlassian User Group Hamburg, 6.6.2012. Topic was migration from Mediawiki and rollout of Confluence in a complex environment with a lot of content.

TRANSCRIPT

Switching to Confluence with 500+ Wiki users

Migrating Bigpoint from Mediawiki to Confluence

AUGHH user group meeting, 6.6.2012,Nils Hofmeister

Agenda

2

• Before Confluence

• The mission

• Status quo

• Learnings

3

Before Confluence

Before Confluence

4

• Time: October 2010

• Bigpoint has >500 employees

• There is a bunch of MediaWiki instances (>50)

• Some customization

Before Confluence

5

Before Confluence

6

We had the wrong tool for the wrong people and it hurt. But barely anybody was aware…

Fortunately there were a couple of people interested in replacing our Wiki by Confluence.

Before Confluence

7

To justify the costs, we used the following arguments:

• Global search

• Spaces

• Role-based permissions

• Connection to Jira

• Versioning + concurrency handling

• All the plugins

• Migration via UWC

In late 2010, we got approval.

The fight for resources started…

8

The mission

The mission

9

Open questions

• How to integrate with Bigpoint IT platform?

The mission

10

Open questions

• How to integrate with Bigpoint IT platform?• Have everything in SVN• Wrap Tomcat daemon so it works with monitoring, Ops automation etc• Use configuration templates for modified files• Setup a staging system

The mission

11

Open questions

• How to integrate with Bigpoint IT platform?• Have everything in SVN• Wrap Tomcat daemon so it works with monitoring, Ops automation etc• Use configuration templates for modified files• Setup a staging system

• Who maintains it?

The mission

12

Open questions

• How to integrate with Bigpoint IT platform?• Have everything in SVN• Wrap Tomcat daemon so it works with monitoring, Ops automation etc• Use configuration templates for modified files• Setup a staging system

• Who maintains it?• My team (Release Engineering)• Right combination of skills and focus, but still…

The mission

13

Open questions

• How to integrate with Bigpoint IT platform?• Have everything in SVN• Wrap Tomcat daemon so it works with monitoring, Ops automation etc• Use configuration templates for modified files• Setup a staging system

• Who maintains it?• My team (Release Engineering)• Right combination of skills and focus, but still…

• How exactly will migration happen?

The mission

14

Open questions

• How to integrate with Bigpoint IT platform?• Have everything in SVN• Wrap Tomcat daemon so it works with monitoring, Ops automation etc• Use configuration templates for modified files• Setup a staging system

• Who maintains it?• My team (Release Engineering)• Right combination of skills and focus, but still…

• How exactly will migration happen?• First sample spaces as example• New “units” go directly to Confluence• Migrate Teams step by step using UWC• => Soft migration

The mission

15

Open questions

• How to integrate with Bigpoint IT platform?• Have everything in SVN• Wrap Tomcat daemon so it works with monitoring, Ops automation etc• Use configuration templates for modified files• Setup a staging system

• Who maintains it?• My team (Release Engineering)• Right combination of skills and focus, but still…

• How exactly will migration happen?• First sample spaces as example• New “units” go directly to Confluence• Migrate Teams step by step using UWC• => Soft migration

• What about Kerberos SSO and AD?

The mission

16

Kerberos

• Not easy to grasp

• Hard to deal with when you are not admin

• Gave us a lot of trouble in Java context

So we used an already existing in-house service:

Behold… LoginProxy!

The mission

17

The mission

18

Integration

• We had a first RC ready in April 2011

• It used LoginProxy for authentication

• It used a cronjob + SOAP for AD sync / authorization

• We had two blades in place for staging + production:• 2x Quad core, 12 GB RAM, 2x 320 GB HDD, SATA, JBOD• Backup etc via Bigpoint standard mechanisms

• Took about 5 man weeks to get everything ready and test it

• Central technology teams started using it

• Administration was cooperation of Release Engineering + IT Engineering

The mission

19

Migration

• No interruption of ongoing projects

• Long migration timeframe (>6 months)

• Lack of acceptance with some users

• UWC results very mixed

• => More users started noticing Confluence…

• Thank god we had a tech writer who could assist with content, support and training

The mission

20

Migration

• Tracking of wiki migration using Jira

• Conversion respecting stakeholder schedules

• Mediawikis still exist, but read-only

• A lot of training• Brown bag meetings• Coaching per group• Update meetings• Confluence space• Examples• …

The mission

21

Result: Success

Specs, 06/2012 (14 month later):

• 971 users

• 152 groups

• 152 spaces (without personal)

• 19.493 pages created

• 34.091 attachments uploaded

“You can find our current documentation in Confluence”-Random Bigpoint employee

22

Status quo

Status quo

23

• In use worldwide• E.g. Hamburg, Berlin, Malta, San Francisco

• Confluence 3.5.13• Balsamiq• Gliffy

• So far 2 custom plugins in development• Custom Jira issue creator• Custom AD synchronizer

• Integration with• Jira

• Issues macros, shortcut links• Application link

• Jenkins• Internal middleware (e.g. mailtool)

Status quo

24

Status quo

25

Next big tasks

Status quo

26

Next big tasks

• Confluence 4• Delayed to avoid shocking our users with 2 major changes within 1 year• Mixed feelings: markup power users, APIs, coaching,…

Status quo

27

Next big tasks

• Confluence 4• Delayed to avoid shocking our users with 2 major changes within 1 year• Mixed feelings: markup power users, APIs, coaching,…

• Better Kerberos Integration• Avoid trouble with cached passwords vs. tool integration• Reduces maintenance efforts and reliability

28

Learnings

Learnings

29

Acceptance

• In general, acceptance was given quickly since• Confluence is fancy• Brings a lot of features• Integrates with Jira nicely

Learnings

30

Acceptance

• In general, acceptance was given quickly since• Confluence is fancy• Brings a lot of features• Integrates with Jira nicely

• Maybe a hard migration would have been easier…• …but we would have had far more haters

Learnings

31

Acceptance

• In general, acceptance was given quickly since• Confluence is fancy• Brings a lot of features• Integrates with Jira nicely

• Maybe a hard migration would have been easier…• …but we would have had far more haters

• Remaining haters could be convinced by• Dedicated trainings + support• New features (e.g. heatmap, role-based security,…) • Fast reactions – when we started: immediate changes

Learnings

32

Acceptance

• In general, acceptance was given quickly since• Confluence is fancy• Brings a lot of features• Integrates with Jira nicely

• Maybe a hard migration would have been easier…• …but we would have had far more haters

• Remaining haters could be convinced by• Dedicated trainings + support• New features (e.g. heatmap, role-based security,…) • Fast reactions – when we started immediate changes

Conclusion: when the field isn’t green, only soft migration works

Learnings

33

Costs

• When we started about 1,5 persons permanently working on Confluence intro

Learnings

34

Costs

• When we started about 1,5 persons permanently working on Confluence intro

• System integration was much more expensive than expected

Learnings

35

Costs

• When we started about 1,5 persons permanently working on Confluence intro

• System integration was much more expensive than expected

• Right now, work on demand• Bug fixes• Plugin development• Coaching of new people• Changes and extensions• Standardization

• Basically, 1-2 persons are permanently working on Confluence one way or the other

Learnings

36

Costs

• When we started about 1,5 persons permanently working on Confluence intro

• System integration was much more expensive than expected

• Right now, work on demand• Bug fixes• Plugin development• Coaching of new people• Changes and extensions• Standardization

• Basically, 1-2 persons are permanently working on Confluence one way or the other

Conclusion: 2 fulltime persons needed for a Confluence of our size and usage scenario: a DevOps guy and a workflow person

Learnings

37

Enterprisy requirements

• Authentication and authorization requires customization

Learnings

38

Enterprisy requirements

• Authentication and authorization requires customization

• Certain IT requirements hard to address• Replication• Failover• Automated deployment

Learnings

39

Enterprisy requirements

• Authentication and authorization requires customization

• Certain IT requirements hard to address• Replication• Failover• Automated deployment

• Some features are not yet convenient enough• Bulk attachment upload• Easy update of attachments (e.g. excel files)• Default groups for new users• Notification email templates• …

Learnings

40

Enterprisy requirements

• Authentication and authorization requires customization

• Certain IT requirements hard to address• Replication• Failover• Automated deployment

• Some features are not yet convenient enough• Bulk attachment upload• Easy update of attachments (e.g. excel files)• Default groups for new users• Notification email templates• …

Conclusion: If you want to customize Confluence significantly, you will need admin and Java dev skills.

41

Summary

Summary

42

• The good• Soft migration via UWC worked for us• Users were happy quickly• The possibilities are awesome

• The bad• The frontend is fancy, maintenance can be weird

• The ugly• It costs quite some manpower for serious operation• It needs continuous effort for acceptance• You need skilled, hard to find people for this

Summary

43

If you want to operate a serious Confluence instance, you need manpower.

But you get the best possible documentation system I know.

Find us on44

Bigpoint GmbH

Alexanderstraße 510178 BerlinGermany

Bigpoint Inc.

500 Howard StreetSuite 300San Francisco, CA 94105

Bigpoint Distribuição de Entretenimento Online Ltda.

Av. Brig. Faria Lima3729 cj. 52804538-905 São PauloBrazil

Bigpoint GmbHNils HofmeisterLead Integration Architect

Drehbahn 47-4820354 Hamburg Germany

Tel +49 40.88 14 13 - 0Fax +49 40.88 14 13 - 11

[email protected]

Contact us

Bigpoint International Services Limited

1 Villa ZimmermannTa’Xbiex TerraceXBX 1035 Ta’XbiexMalta

Find us on

45

Bigpoint GmbHFirst name, last name

Title

Drehbahn 47-4820354 Hamburg

Germany

Tel +49 40.88 14 13 - 0Fax +49 40.88 14 13 - 11

[email protected]