The Quickr Domino to Connections 5.0 migration tool is released and this document is designed to bring a customer through the migration with as much ease as possible.

Table of Contents:

Prerequisites:

Configuration:

Prerequisites:

Questionnaire -

Quickr Domino:

What Operating System is the Quickr Domino on?

What version of Domino is the Quickr Domino server 8.51 or 8.53? ( Should be at Domino 8.5.3FP1 or Domino 8.5.1FP5 )

What is the current version of the Quickr Domino server including Hotfix number? ( Should be at Quickr Domino Hot Fix 47 - For Domino 8.5.1 or Quickr Domino Hot Fix 47 - For Domino 8.5.3 )

What type of LDAP is used? and is it the same LDAP directory that Connections uses

Give an example of the customer's LDAP structure e.g. CN=test name,OU=Group,O=Country ?

Connections:

Is this a new installation of Connections? How long has Connections been installed?

What Operating System is the Connections Server on,

Is CCM installed on the same operating system?

What is the name of the FileNet Administrator and is it suitable for the users to receive emails from this user, view content in the Activity Stream from this user or see that Quickr Docs with no Owner will now have this person as the owner..

The FileNet administrator must be listed in LDAP and be a FileNet Administrator.

What type of LDAP is used? and is it the same LDAP directory that Quickr uses

Give an example of the customer's LDAP structure e.g. CN=test name,O=Country ?

Data:
What is the overall size of the Quickr data?
How many Places are to be migrated?
What is the type of content to be migrated, Libraries\Blogs\Wiki\Tasks

What is the type of documents to be migrated? Uploads\Pages\ Imported Files \ Microsoft Forms

Is there any Custom Forms?

Is there secure content in the Places? Folder ACL's \ Document ACL's \ Rooms with partial Member lists

Is there any Customisations, if there is then please describe them.

Misc:

What is the location of the servers. it is better to have them close to each other as there will be a lot of traffic between them?
Mapping files: who is going to create the mapping files?

Configuration:

Qpconfig.xml

 <person_ldap_dump_file>C:\LDAPdump\collect_user.dns</person_ldap_dump_file> 

 <person_ldap_dump_file>C:\LDAPdump\collect_groups.dns</person_ldap_dump_file> 

 <expand_external_groups enabled="true" max_depth="3" number_limit="100"/> 

 <special_char_encoding_mode>underline</special_char_encoding_mode> 

 <ConnectionVersion enable="true" version="5.0CR2" defaultValue="$IC-T-I-a"/> 

 <replace_second_cn_to_ou enabled="true"/> 

 <activeXDocuments>true</activeXDocuments> 

 <debugRoomName>PageLibrary8825798B00032868.nsf</debugRoomName> 

 <combination_document_name enabled="true"/> 

 <ccm_owner_role>Editor</ccm_owner_role> 

 <domino_native enabled="true"/> 

 <hide_restricted_document_name enabled="true"/> 

 <person_mapping_file>c:\LDAPdump\usermapping.txt</person_mapping_file>  

 <group_mapping_file>c:\LDAPdump\groupmapping.txt</group_mapping_file>  

JavaUserClassesExt

A change was made to the FixPack installer 8.5.*.44 that one entry gets added automatically and the rest of the lines get added but are commented out, So you need to uncomment these lines before we can run a migration,

So the original notes.ini looks like this:

JavaUserClassesExt=QPJC1,QPJC2,QPJC3,QPJC4,QPJC5,QPJC6,QPJC7,QPJC8,QPJC9,QPJC10,QPJC11,QPJC12,QPJC13,QPJC14,QPJC15,QPJC16,QPJC17,QPJC18,QPJC19

QPJC1=C:\dominoDir\quickplace.jar

QPJC2=C:\dominoDir\log4j-118compat.jar

QPJC3=C:\dominoDir\xsp\proxy\WEB-INF\lib\commons-httpclient-3.0.1.jar

QPJC4=C:\dominoDir\xsp\proxy\WEB-INF\lib\commons-codec-1.3-minus-mp.jar

QPJC5=C:\dominoDir\xsp\shared\lib\commons-logging.jar

QPJC6=C:\dominoDir\abdera-core-0.4.0-incubating.jar

QPJC7=C:\dominoDir\abdera-i18n-0.4.0-incubating.jar

QPJC8=C:\dominoDir\abdera-parser-0.4.0-incubating.jar

QPJC9=C:\dominoDir\axiom-impl-1.2.5.jar

QPJC10=C:\dominoDir\axiom-api-1.2.5.jar

QPJC11=C:\dominoDir\jaxen-1.1.1.jar

QPJC12=C:\dominoDir\poi-3.6.jar

QPJC13=C:\dominoDir\commons-io-1.4.jar

QPJC14=C:\dominoDir\commons-fileupload-1.2.jar

QPJC15=C:\dominoDir\odfdom.jar

QPJC16=C:\dominoDir\poi-ooxml-3.6-20091214.jar

QPJC17=C:\dominoDir\poi-ooxml-schemas-3.6-20091214.jar

QPJC18=C:\dominoDir\xmlbeans-2.3.0.jar

QPJC19=C:\dominoDir\dom4j-1.6.1.jar

After installing the FixPack 8.5.1.44 or later with the FixPack Installer, the notes.ini will be updated like so:

JavaUserClassesExt=QPJC1,QPJC3,QPJC4,QPJC5,QPJC6,QPJC7,QPJC8,QPJC9,QPJC10,QPJC11,QPJC12,QPJC13,QPJC14,QPJC15,QPJC16,QPJC17,QPJC18,QPJC19,QPJC20,QPJC21,QPJC22,QPJC23,QPJC24,QPJC25,QPJC26

QPJC1=C:\dominoDir\quickplace.jar

QPJC3=C:\dominoDir\xsp\proxy\WEB-INF\lib\commons-httpclient-3.0.1.jar

QPJC4=C:\dominoDir\xsp\proxy\WEB-INF\lib\commons-codec-1.3-minus-mp.jar

QPJC5=C:\dominoDir\xsp\shared\lib\commons-logging.jar

QPJC6=C:\dominoDir\abdera-core-0.4.0-incubating.jar

QPJC7=C:\dominoDir\abdera-i18n-0.4.0-incubating.jar

QPJC8=C:\dominoDir\abdera-parser-0.4.0-incubating.jar

QPJC9=C:\dominoDir\axiom-impl-1.2.5.jar

QPJC10=C:\dominoDir\axiom-api-1.2.5.jar

QPJC11=C:\dominoDir\jaxen-1.1.1.jar

QPJC12=C:\dominoDir\poi-3.6.jar

QPJC13=C:\dominoDir\commons-io-1.4.jar

QPJC14=C:\dominoDir\commons-fileupload-1.2.jar

QPJC15=C:\dominoDir\odfdom.jar

QPJC16=C:\dominoDir\poi-ooxml-3.6-20091214.jar

QPJC17=C:\dominoDir\poi-ooxml-schemas-3.6-20091214.jar

QPJC18=C:\dominoDir\xmlbeans-2.3.0.jar

QPJC19=C:\dominoDir\dom4j-1.6.1.jar

QPJC20=C:\dominoDir\log4j-1.2.14.jar

#QPJC21=C:\dominoDir\Jace.jar

#QPJC22=C:\dominoDir\stax-api.jar

#QPJC23=C:\dominoDir\xlxpScanner.jar

#QPJC24=C:\dominoDir\xlxpScannerUtils.jar

#QPJC25=C:\dominoDir\abdera-client-0.4.0-incubating.jar

#QPJC26=C:\dominoDir\jsoup-1.6.1.jar

Note: The QPJC2 line has been removed and QPJC2 is removed from JavaUserClassesExt.

The QPJC20 line has been added and QPJC20 has been added to JavaUserClassesExt.

QPJC21-26 have been added and are commented out, please remove the # character to load the .jar files.

ConnectionsServerURL

e.g. ConnectionsServerURL=https://connections.ibm.com
Note: that this uses https, The migration tool will use this url to connect to the Connections server to create the Community that the Place will be migrated into.


FilenetURL

e.g. FilenetURL=http://filenet.ibm.com

Note: that this uses http and not https, The migration tool will use this url to connect to the FileNet server to create the Libraries in the Connections Community.

ObjectStore
e.g. ObjectStore=ICObjectStore

This is added by the installer, please verify it.
The value of this can be found by using http://filenet.ibm.com\acce to look-up the name of the ObjectStore, It will be under ICDomain\Object Stores.

TopTargetFolderForMigration

e.g. TopTargetFolderForMigration=/ClbTeamspaces

This is added by the installer, please verify it.

Since Connections 5.0 the libraries are stored under the ClbTeamspaces folder and then Year\Month. The code will add the Year\Month, and generally the location will not change, so stick with the example above.

QuickPlaceJavaLogging (optional)
e.g. QuickPlaceJavaLogging=3
This is for debugging and the range is 1-3.. use the example above if debugging...

Java.policy

This file is located at \jvm\lib\security directory.

The following entries are appended to the end of the file by the fixpack installation. Verify that this has been done by the installer.

FileNet Security changes

Grant all permission access rights to the privileged user specified when running qptool migration command, in order to be able to modify the created time and owner property of the new created document using the privileged user.

Open ACCE (Administration Console for Content Platform Engine) web console

1, 2, Navigate to the Object Store you are working on and then open the "Security" tab.

3, 4, Select the privileged user and click "Edit" button to prompt the "Edit Permissions" dialog box.

5, 6, Choose "Custom" in the "Permission group" drop-down list, mark all listed permission, and then

7, click "OK" to grant all permission access rights to the privileged user.

8, Click the "Save" button to save the changes to object store setting.

Grant the authenticated users the permission to view the folder description after migration.

Open ACCE (Administration Console for Content Platform Engine) web console

1, 2, 3, 4, Navigate to the Object Store you are working on, and then click Data Design > Classes > Custom Objects > Quickr Folder Properties

5, Open the "Default Instance Security" tab.

6, 7, Select "#AUTHENTICATED-USERS" and then click "Edit" button to prompt the "Edit Permissions" dialog box.

9, Choose "View Properties" in the "Permission group" drop-down list, and then click "OK" to grant authenticated users group the permission to view this object.

10, Click the "Save" button to save the changes to object store setting.

Note: if the user "#AUTHENTICATED-USERS" does not exist in the Users and Groups list, you need to add it using the following steps:

1, Click the "Add" button to prompt the "Add Users and Groups" dialog box.
2, 3, Select "Display name" and "Starts with", and enter "#" as the search criterion, then click "Search" button to execute the search condition.
4, 5, 6, Select "#AUTHENTICATED-USERS" from the "Available Users and Groups", and click the right arrow to add it to "Selected Users and Groups".
7, Click "OK" button to add the user..
8, Click the "Save" button to save the changes to object store setting

Changing the FileNet Administrator user to an LDAP user – This section is only needed if you do not have an LDAP user as a FileNet Administrator. If you already have an LDAP user as a FileNet Administrator please skip this section.

See the Doc to find the information on how to Change the FileNet Administrator user to an LDAP user

Running a Test Migration.

Migrating a Test Form

Migrating a form is the most basic form of migration as migrating a form does not involve any interaction with creating a Community or any other form of interaction with Connections. It is Quickr Domino to FileNet actions. The action of migrating a test form verifies that you have the correct access and configuration to work with CCM\FileNet.

Create a Test Place called testplace in Quickr Domino.

Create 1 simple test form and add 1 text field to the form.

Open the Quickr Domino console and run the following command

“load qptool getcustomizedforms -p testplace -o testplace.xml”

-p testplace ==> is the name of your testplace

-o testplace.xml” ==> is the name of the output file in the Domino Program folder.

This extracts the details of the test form from the Place and adds it to a .xml file

Now, open the testplace.xml that has been generated and make some changes, the text should look as follows.

<?xml version="1.0"?>

<service>

<servers>

<server>

<hostname>testserver.acme.com</hostname>

<places>

<place>

<name>testplace</name>

<room migrate="false" name="testplace" nsf="Main.nsf">

<customizedForm description="" migrate="false" name="TestForm" unid="69DB62306126887E80257E7200710970">

<customizedField dataType="h_TextInput" descriptionText="" displayName="TextField" isRequired="false" name="c_TextField"/></customizedForm>

</room>

<action_status action="getCustomizedForms">

<code>0</code>

<start_time><![CDATA[20150628T215449,348+0100]]></start_time>

<end_time><![CDATA[20150628T215449,489+0100]]></end_time>

</action_status>

</place>

</places>

</server>

</servers>

</service> 

Change the 2 entries that say “false” and change then to “true” as follows.

 <?xml version="1.0"?>

<service>

<servers>

<server>

<hostname>testserver.acme.com</hostname>

<places>

<place>

<name>testplace</name>

<room migrate="true" name="testplace" nsf="Main.nsf">

<customizedForm description="" migrate="true" name="TestForm" unid="69DB62306126887E80257E7200710970">

<customizedField dataType="h_TextInput" descriptionText="" displayName="TextField" isRequired="false" name="c_TextField"/></customizedForm>

</room>

<action_status action="getCustomizedForms">

<code>0</code>

<start_time><![CDATA[20150628T215449,348+0100]]></start_time>

<end_time><![CDATA[20150628T215449,489+0100]]></end_time>

</action_status>

</place>

</places>

</server>

</servers>

</service>

Save the file.

In the Domino console, run the command

“load qptool migratecustomizedforms -i testplace.xml -u admin -pw password -o migration.xml”

-i testplace.xml ==> is the name of the input file that you have edited in the previous step.

-u admin ==> the name of the migration administrator

-pw password ==> the administrator's password

-o migration.xml” ==> the name of the output file that stores the result of the migration.

Open the migration.xml and verify that the migration has been successful, (0 is successful)

Use ACCE to verify that the form has been added to FileNet

Basic Mapping files with no TDI needed

Before migrating a Place we need to have entries in the mapping files. In this case we are assuming that we are using a different LDAP for Quickr Domino and Connections.

So add 2 test users to the Quickr Place that we have previously created. ( Testing User1 and Testing User2 )

Open the file collect_user.dns that you have named in the qpconfig.xml setting

The first line can be as follows but it is purely optional ==> ConnectionsDN;ConnectionsUUID

These can be found stored on the Connections server in the TDI folder in a file called collect.dns, pull out the 2 sample names from this file and add them into the collect_user.dns

The collect_user.dns should now look like this

ConnectionsDN;ConnectionsUUID

CN=Testing User1,OU=Users,O=901;

CN=Testing User2,OU=Users,O=901;

.

Note: If the Connections LDAP is Active Directory, then use the shortname instead of the full dn name as the ConnectionsDN, in this case your collect_user.dns should now look like this

ConnectionsDN;ConnectionsUUID

CN=TUser1;

CN=TUser2;

.

Now we need the ConnectionsUUID so open Connections and go to the Profiles\Directory so we can search for Profiles.

Next we hover over the user and do a copy image location if using FireFox

This gives us the url of the users Profile and also the UNID

http://acme.ibm.com/profiles/photo.do?r=true&small=false&userid=DA3BD999-8691-DDD6-8025-7D25004ED97A&etag=20150409.125116

Do this for both users and the collect_user.dns should now look like this

CN=Testing User1,OU=Users,O=901,O=901;DA3BD999-8691-DDD6-8025-7D25004ED97A

CN=Testing User2,OU=Users,O=901,O=901;D77E5DF4-7F63-D33A-8025-7D25004EE326

.

For testing this is the collect_user.dns completed. If you have a second LDAP for Connection then do the following, if not go straight to Migrating a Test Place.

.

Open the file usermapping.txt that you have named in the qpconfig.xml setting

The first line can be as follows but it is purely optional ==> DNfromQD;DNfromConnections

The first part of the second line is the DN for the first User from Quickr. To locate this open the contacts1.nsf of the test Place using the Domino Administrator and go to the Default view, here you can see the name of the 2 users,

Check the document properties and the field h_Alias, if the Alias has comma separators then use this in the collect_user.dns.

So our usermapping.txt should look like this

DNfromQD;ConnectionsDN

CN=Testing User1,O=901

CN=Testing User2,O=901

Next we need the DN from Connections. The second part of the second line is the DN that we already used in the collect_user.dns, add these to the usermapping.txt and it should now look like this

DNfromQD;ConnectionsDN

CN=Testing User1,O=901;CN=Testing User1,OU=Users,O=901

CN=Testing User2,O=901;CN=Testing User1,OU=Users,O=901

Note: If the Connections LDAP is Active Directory, then use the shortname instead of the full dn name as the ConnectionsDN, in this case your usermapping.txt should now look like this

DNfromQD;ConnectionsDN

CN=Testing User1,O=901;CN=TUser1

CN=Testing User2,O=901;CN=TUser1

.

Now we have enough gathered in the mapping files to migrate the Test Place.

..

Migrating a Test Place

Next we will migrate the test Place,

Open the Quick Domino Console and run the following command

load qptool migration -p testplace -u admin -pw password

-p testplace ==> the name of the Place

-u admin ==> the name of the migration administrator

-pw password ==> the administrator's password

Open the qptool.migration.xmll and verify that the migration has been successful, (0 is successful)

Open the new Community in Connections called TestPlace and verify that the members have been carried over from Quickr Domino and that the Library has been added as an App.

Migrating Test documents and folders.

Login to the Quickr Domino test Place using the 2 test user accounts and add several Documents and Folders to the Quickr Domino Place, now migrate the test Place

Open the Quick Domino Console and run the following command

load qptool migration -p testplace -u admin -pw password

-p testplace ==> the name of the Place

-u admin ==> the name of the migration administrator

-pw password ==> the administrator's password

Open the qptool.migration.xmll and verify that the migration has been successful, (0 is successful)

Open the new Community in Connections called TestPlace and verify that the members have been carried over from Quickr Domino and that the Library has been added as an App.

Open the Library and check the newly created documents and folders.

Congratulations you have carried out a test migration from Quickr Domino to CCM.

Mapping Person and Groups to UNID for Domino

//

// This is a simple parser that returns one line at a time from

// the input stream.

//

var counter = 0;

function function_map_from_dominoUNID(fieldname) {

var byteString = null;

var canonicalString = "";

var attr = entry.getAttribute("dominoUNID");

if(attr != null) {

byteString = attr.getValue(0);

var canonicalString = "SSSSS";

if(byteString != null) {

canonicalString = "HHHH";

canonicalString = com.ibm.connections.directory.services.util.ObjectGUIDConverter.convertByteStringToGUIDString(byteString);

} 

else {var canonicalString = "VVV";}

}

else {var canonicalString = "DDD";}

return canonicalString;

}

function writeEntry ()

{

var type = entry.getString("objectclass");

if(type == "dominoPerson")

{

var person_dn = entry.getString("$dn");

var index = person_dn.indexOf(",");

if(index != -1)

{

person_dn = person_dn.replace(/,/g, "/");

}

out.write (person_dn);

out.write (";");

out.write (function_map_from_dominoUNID());

out.newLine();

}

 if(type == "dominoGroup")

{

var group_dn = entry.getString("$dn");

var index = group_dn.indexOf("CN=");

if(index == 0)

{

group_dn = group_dn.substring(3);

}

out.write (group_dn);

out.write (";");

out.write (function_map_from_dominoUNID());

out.newLine();

}

if(type != "1")

{

out.write ("Q");

out.newLine();

 }

}

function readEntry ()

{

var str = inp.readLine();

if (str == null) {

result.setStatus (0);

result.setMessage ("End of input");

return;

}

counter++;

entry.setAttribute ("line", str);

result.setStatus (1);

}

function querySchema ()

{

var e = new com.ibm.di.entry.Entry();

e.addAttributeValue("name","line");

e.addAttributeValue("syntax","String");

list.add(e);

result.setStatus (1);

} 

Mapping Person to Person for different LDAPs Domino to TDS

Return to the TDI Configuration Editor. Right click on AssemblyLines and choose New AssemblyLine.

Enter CreateUserDNMapping for the new AssemblyLine name and click Finish.

Click Add Component.

Enter ldap in the search box and select LDAP Connector from the Components list. Change the name to ConnectionsLDAP and set the mode to Iterator. Click Next.

Since this TDISOL installation is already configured to connect to the LDAP servers, those same references from the properties file can be used here. Properties are used by clicking on the labels, as shown below. By using the properties we can more easily change these parameters in a single properties file rather than having to modify the connectors manually.

Select the Use Property option. Select the source_ldap_url property from the list. Click OK.

Repeat the process for the following labels.

Login username.

Login password

Search base.

Search filter.

The values from the properties file are populated to the connector configuration. The values are now managed in the properties file rather than the connector configuration. Click Finish.

Select the Input Map tab and click Connect.

Click Next several times to iterate through the list of LDAP entries. The LDAP schema is automatically populated by the attributes retrieved from each entry. Click Close to close the session.

Drag the $dn and mail attributes from the Schema list to the Work Attribute column.

Click Add component.

Create another LDAP Connector called DominoLDAP and click Next. Click on the LDAP URL label.

Select Use Property. New properties are created since the TDISOL environment is not configured to access the Quickr Domino LDAP server. Click Add property.

Select profiles.tdiproperties for the Store Name. Enter quickr_domino_ldap_url for the property name and ldap://quickr01.itso.ibm.com:389 for the value.

Verify the information previously entered and click OK.

Repeat the process for the LDAP user login.

User login password.

Clear the Search Base and set the Search Filter to mail=*. This returns only person entries that contain an email address.

Click Connect to verify that we can access the directory. Click Next several times to populate the Schema attribute list. Click Close to close the connection.

Drag the $dn attribute to the Work Attribute column of the Input Map. Rename the $dn entry in the Work

Attribute column to QuickrDN.

Click the Link Criteria tab. Click Add. Select mail on the left side (Quickr Domino) and $mail (Connections LDAP) on the right. If there is a different set of attributes that are used to link the Domino and Active Directory users, use those attributes here. Be sure to add the new attribute to the Input Map of the Iterator.

Because we added a new property that contains a password, we can encrypt the password to remove the clear text password from the property file. Open the profiles property file (reload if prompted). Locate the new password property and change the value in the Protected column to true. Click Send the properties to Server and save the changes.

The password hash can be viewed by clicking on the value.

Select the DominoLDAP connector. Select the Hooks tab and check the On No Match checkbox under DataFlow - Lookup. Enter the following in the text box. Execution flows to this hook in the event that there is no match found in the Quickr Domino LDAP. The mail address of the entry that can not be located is printed in the log and execution continues with the next LDAP entry in the Iterator.

An exception is generated and the processing stops if you do not trap for the possibility of returning multiple entries for a particular mail address. These lines in the On Multiple Entries hook print the error to the log file and continue execution with the next entry in the Iterator. In a perfect world this hook should never execute as the email address in the Domino Directory should be unique. However, it is prudent to trap for it.

Click Add Component. Enter file in the search box and select the File System Connector from the Components list. Name it WriteDNMapping and select AddOnly as the mode and click Next.

Set the file name to person_mapping.csv. The file name is relative to the TDI solutions directory, which is /root/QuickrMig/TDI. Click Next.

Select CSV Parser.

The Field Separator should be ';' by default. Expand the Advanced section.

Enter QuickrDN followed by $dn in the Field Names box. The order must be as shown. Uncheck Enable Quoting and Write header. Add UTF-8 to the Character Encoding field. Click Finish.

Double click the "[Empty map.." text in the Output Map.

Select $dn and QuickrDN and click OK.

The output map should be as follows.

Click Add Component. Enter "if" in the search box and select the IF component. Set the name to IfNoMail and click Next.

Click Add. Select mail from the Attribute list, check Not, and set the operator to "has value(s)". Click Finish. This sets the conditional to true if the mail attribute is missing, empty, or null.

Click Yes to add a new branch. This new branch executes if the previous IF connector conditional return true.

Check the Scripts radio button and select the Empty Script component. Set the name to SkipEntry and click Finish.

Enter system.skipEntry(); in the text box. This causes the execution to continue to the next entry in the ConnectionsLDAP iterator.

Drag the newly created IF component directly in front of the DominoLDAP connector.

Select the WriteDNMapping component and select the Hooks tab. Check the Before Execute hook and enter the following line. Since Quickr is using native Domino authentication, we need to convert the LDAP DN format to the Notes name format. This is done by replacing the "," with "/". If Domino LDAP is used for Quickr authentication, then this line can be removed.

Save the AssemblyLine and click Run in console.

Examine the contents of the person_mapping.csv file in the /root/QuickrMig/TDI directory. The contents should be similar to the following.

CN=Matt Ayer/O=itso;CN=Matt Ayer,OU=ITSO,DC=ad,DC=ITSO,DC=net

CN=Amy Blanks/O=itso;CN=Amy Blanks,OU=ITSO,DC=ad,DC=ITSO,DC=net

CN=Peter Brown/O=itso;CN=Peter Brown,OU=ITSO,DC=ad,DC=ITSO,DC=net

Running the Migration

Understanding the environment

Before migrating the production Quickr Domino Places to a Connections server it is good practice to analyse the Places to see how what data will be migrated and how it will be migrated.

What's covered by the migration tool.

Rooms, Folders, Homes pages

Documents created from uploads, imports, pages, simple custom forms, and Microsoft office forms will be migrated to CCM.

The metadata information of creator, last editor, created timestamp, last updated timestamp will all be migrated with the documents and folders. Versions and comments will be migrated together with the documents. Simple custom forms will be migrated to CCM as document classes.

What's NOT covered by the migration tool.

• Wiki and Blog places.
• Task, Calendar, forum, list, link, or Templates.
• Html forms and the documents based on the html forms
• Draft. All drafts need to be completed before migration.
• Workflows. All workflows need to be completed before migration.
• Content in the Trash will not be migrated
• Local members.
• Restricted Access: Docs\Folders\Rooms
  To check what elements have restricted access in Quickr. Run the following command
  load qptool getrestrictedresourcelist -p nameofplace
  The result is a xml file that will list all restricted elements in a Place.

Follow this link to find out more information about sample agents that will analyse the Quickr Domino server and report on the type of documents stored in the Quickr Places.

Access Models – Users

The mapping of the access roles from Quickr Domino to Connections can be seen in the following 3 tables.

Quickr Domino Place level => Connections Library Access

Rooms & Folders => Folders

Documents ==> Documents

Groups

Quickr Domino Place => Connections Library Access

- If a group is an owner or manager in a Place, it is expanded to individual members and migrated to a community as person owners.

Note: Groups cannot be owners in Connections Communities

- If a group is reader, author, or editor in a place, it is migrated as a group as a community member.

Migrating custom forms

There is a limit to the amount of custom forms that can be migrated, this is realised when running the qptool migratecustomized forms command, if you notice a runtime exception reporting, “The row length limitation of the underlying database has been exceeded, incapable of creating document class any further,” it means you are not able to migrate customized forms any further.

The cause of this is the underlying database which stores the field info has a row length limitation of 32K, It is recommended that customized forms be migrated by prioritizing from most significant to least significant,

See this link for more details on migrating the custom forms and this related issue: http://www-10.lotus.com/ldd/lcwiki.nsf/xpDocViewer.xsp?lookupName=Early+Release+-+Quickr+for+Domino+Migration+Guide#action=openDocument&res_title=Installing_and_configuring&content=pdcontent

See the earlier section on the steps to migrate Custom Forms.

getcustomizedforms: Gets a customized forms list from the specified place.

Usage:

qptool getcustomized forms [–?] (–a | –p | –i ) [–o ]

Where:

–? Prints out this usage message.

–a Gets customized forms from all places on the server.

–p Space-separated list of places to get customized forms from.

–i Input file specifying places to get customized forms from.

–o Specifies the output file. (Default: qptool.getcustomizedforms.xml)

migratecustomizedforms: Migrate a customized forms list from the specified place input list.

Usage:

qptool migratecustomizedforms [–?] -u -pw -i [-o ]

Where:

–? Prints out this usage message.

–u Specifies the user name of the privileged account to run the migration.

–pw password Specifies the password of the privileged account to run the migration.

–i Input file specifying places to be migrated.

–o Specifies the output file. (Default: qptool.migration.xml)

Migrating a Place

See the earlier section on the steps to migrate a Place.

Usage:

load qptool migration [-p (place list)] [-a] [-i input.xml] -u username -pw password

Where:

–p Specifies a single place or a list of places to migrate.

–a Migrates all places.

–i input.xml Specifies the places list in the xml file.

–u Specifies the administrator account used for migration.

–pw Specifies the administrator account password.

Update FileNet to limit the reporting of the migration in Activity Streams

See this Doc for more information on how to do this...

Troubleshooting

Cover troubleshooting .ser files ...