In QuickPlace, many things that users would consider "design", including custom pages and custom fields, are actually stored as data documents. When doing a design analysis, Notes Migrator for SharePoint treats these things as design documents, not data documents. Furthermore, it takes into account that the actual Notes design elements used by Lotus to implement QuickPlace functionality under the hood are irrelevant for purposes of computing complexity of your migration job.
The following screen shots show this special logic in action:
#1: Analyzing QuickPlace pages by QuickPlace page type (dialog expanded for the sake of the screen shot):
![clip_image002[3]](/Media/WindowsLiveWriter/QuickPlaceAnalysis_B9AE/clip_image002[3]_thumb.jpg)
#2: All “design elements” (QuickPlace page types, fields, folders, skins, etc.)
![clip_image002[5]](/Media/WindowsLiveWriter/QuickPlaceAnalysis_B9AE/clip_image002[5]_thumb.jpg)
#3: Locating customizations – finding “design elements” that are different than the Place type (design template)
![clip_image002[7]](/Media/WindowsLiveWriter/QuickPlaceAnalysis_B9AE/clip_image002[7]_thumb.jpg)
#4: For fun, I built a custom view that sorted all QuickPlace databases by percent match to the base template. 100% means “not customized”.
![clip_image002[9]](/Media/WindowsLiveWriter/QuickPlaceAnalysis_B9AE/clip_image002[9]_thumb.jpg)
Similarly, Notes Migrator for SharePoint properly ignores the many configuration documents in a typical QuickPlace when doing a data analysis.