Migration
of
Controlled
Do ments into
Documents
into
Compliant
SharePoint
Document
Management
Systems
Presented
by:
Joe
Lucadamo
F
d C
l i
Focused
Consulting
The
views
and
opinions
expressed
in
the
following
PowerPoint
slides
are
those
of
the
individual
presenter
and
should
not
be
attributed
to
Drug
Information
Association,
Inc.
(“DIA”),
its
directors,
officers,
employees,
volunteers,
members,
chapters, councils, Special Interest Area Communities or affiliates, or any
chapters,
councils,
Special
Interest
Area
Communities
or
affiliates,
or
any
organization
with
which
the
presenter
is
employed
or
affiliated.
These
PowerPoint
slides
are
the
intellectual
p p
property
y
of
the
individual
presenter
p
and
are
protected
under
the
copyright
laws
of
the
United
States
of
America
and
other
countries.
Used
by
permission.
All
rights
reserved.
Drug
Information
Association,
DIA
and
DIA
logo
are
registered
trademarks
or
trademarks
of
Drug
Information Association Inc All other trademarks are the property of their
Information
Association
Inc.
All
other
trademarks
are
the
property
of
their
respective
owners.
What
is
This
Presentation
About?
•
Overview of SharePoint
Overview
of
SharePoint
–
What
it
is,
how
it’s
structured
To provide framework for this presentation
–
To
provide
framework
for
this
presentation
•
The
migration
process
What
is
This
Presentation
Not
About?
•
How to configure SharePoint
How
to
configure
SharePoint
•
How
to
validate
SharePoint
S
ifi
fi
d
i d Sh
i
•
Specific
configured
or
customized
SharePoint
Presentation
Assumptions
•
SharePoint is validated
SharePoint
is
validated
•
SharePoint
implementation
meets
some
or
all
of the regulatory requirements for compliance
of
the
regulatory
requirements
for
compliance
Key
Terms:
Traditional
EDMS
vs.
SharePoint
Traditional
EDMS
• Current
market
leaders
in
EDMS
• Documentum solutions,
QUMAS
SharePoint
• Microsoft
EDMS,
collaboration,
and
web
site
software
, Q
DocCompliance,
Pilgrim,
MasterControl,
etc.
• Typically
dedicated
to
compliance
EDMS solutions
• Highly
configurable
but
not
out
‐
of
‐
the
‐
box
dedicated
compliance
EDMS
• FDA
‐
regulated
industries
showing
increasing interest in SharePoint
EDMS
solutions
• Key
Terms:
• Document
as
a
combined
object
(content,
renditions,
metadata,
increasing
interest
in
SharePoint
• Key
Terms:
• Document
as
multiple
objects
• No
renditions
previous
versions)
Renditions
• Content
Databases:
Oracle,
MSSQL
Migrations
from
One
Traditional
EDMS
to
Another
Traditional EDMS
Different Traditional EDMS
Traditional
EDMS
Different
Traditional
EDMS
Migration
from
Traditional
EDMS
to
SharePoint
Traditional EDMS
SharePoint
Traditional
EDMS
SharePoint
Traditional
EDMS
Document
Objects
Traditional
EDMS
D
t Obj t
Document Object
Document
Object
Document
Object
Native
Content
An electronic “document” consists of
native content, metadata, signature
data, and a dynamically generated PDF
Metadata
rendition.
This is represented as one document
object in the system – the user sees
onl one entr
Signature
Data
only one entry.
Whereas in standard SharePoint
systems…
SharePoint
Document
Objects
Document
Object
1
Document
Object
2
Document Object Document Object Native Content Metadata PDF Content Metadata Metadata Metadata Signature Data Signature Data
Traditional
EDMS
Architecture
Traditional
EDMS
A hit t
PDF Render
Other EDMS
Architecture
Render
Solution
Other
EDMS
Components
Custom solutions that sit directly on a
database layer.
EDMS Solution
These solutions are designed to meet
compliance requirements for FDA‐
regulated industries.
EDMS
Solution
Traditional EDMS products typically
have an integrated PDF render
solution.
SharePoint
Architecture
Sh
P i t A hit t
Render
Other
EDMS
SharePoint
Architecture
Solution
Components
SharePoint is a standardized EDMS
platform, that is designed to meet
generic document management
EDMS
Solution
needs.
Customized EDMS solutions sit on top
of the SharePoint platform to meet
ind str specific req irements
SharePoint
SharePoint
API
industry‐specific requirements. SharePoint does not provide an
integrated PDF render solution.
MSSQL
Database
The SharePoint API is used to interact
programmatically with the SharePoint
Migration
Process
Stages
Export
Transform
Load
Export
Transform
Load
Compliance
complexity
is
the
greatest
at
the
Transform
stage
Export:
Introduction
Exporting from an existing solution is
Exporting
from
an
existing
solution
is
straightforward,
provided
you
account
for
the
following key components:
following
key
components:
• Document
metadata
• Document
content
(native
and
renditions)
• Electronic
signatures
• Change
Request
history
• Audit
information
Export:
Risks
&
Mitigation
D
t
• Proper
requirements
definition
• Content
counts
to
verify
source
and
exported
documents
Documents
Missed
• Clean
‐
up
in
the
source
system,
if
possible
• Clean
‐
up during the Transform stage
Corrupted
Clean up
during
the
Transform
stage
• Customize
destination
system
to
work
with
available
data
Data
• Establish
timeline
to
close
out
all
open
revision
cycles
in
the
Transform:
Introduction
•
The work of transforming
The
work
of
transforming
data
requires
the
skills
of:
–
Subject Matter Experts
–
Subject
Matter
Experts
–
Technical
Experts
Y
t t
f
•
You
cannot
transform
your
data
until
you
know
what
it
i
d h
it i
i
Transform:
Planning
• What
business
requirements
are
driving
this
new
implementation?
• What changes would you
like to
make in
Business
Requirements
What
changes
would
you
like
to
make
in
the
new
system?
Requirements
• What
changes
do
you
have
to
make
to
the
data to meet new system requirements?
Technical
data
to
meet
new
system
requirements?
• What
can
you
do
in
the
new
system
that
Technical
Transform:
Typical
Business
Requirements
Document Type
Custom Attribute
Document
Type
Consolidation
• Streamline
system
configuration
• Revise design to
Custom
Attribute
Cleanup
• Modify
existing
values
to
meet
new
syntax
Existing
Attributes
• Map
existing
attributes
to
new
attributes
New
Attributes
• Determine
rules
for
populating
new
attributes
• Revise
design
to
meet
current
business
needs
syntax
• Correct
data
inaccuracies
attributes
• Identify
attributes
to
be
brought
over
“as
‐
is”
• Identify
attributes
attributes
• Assign
SMEs
to
generate
the
new
data
to
be
transformed
Proper
planning
at
this
stage
is
critical
to
defining
the
scope
of
the
migration
effort.
Transform:
Typical
(Hidden)
Technical
Requirements
Critical
Compliance
Data
• Document
Names/Numbers
• Document Titles
New
Required
Data
• New
mandatory
system
attributes
• New system
Data
Type
Matching
• Special
characters
• Date/DateTime matchups
D t
l
• Document
Titles
• Document
relationships/references
• Signatures
R
diti
• New
system
architecture/functions
• Data
cleanup
• Renditions
The
technical
team
should
review
these
key
requirements
and
provide
feedback
to
What
About
Electronic
Signatures
on
Exported
Content?
• Content
may
be
migrated
as
‐
is
• Some
banding/watermarking
may
need
to
be
d
d i
t
PDFs
Contain
done
during
export
Signatures
• A
tool
may
be
needed
to
extract
metadata
signatures and fuse them to the exported PDF file
PDFs
Do
N t
C
t i
• Rely
signatures
on
a
custom
and
fuse
SharePoint
them
to
the
solution
exported
to
replicate
file
the
functionality
of
the
legacy
system
Not
Contain
Signatures
Transform:
Risks
&
Mitigation
• Proper
requirements
definition
• QA
Verification
Plan
• Automated
data
verification
against
destination
system
Improper
Data
Transformation
• Manual
correction
of
content
f
bl d
Content
Corruption/Missing
• Mitigation
strategy
for
unrecoverable
documents
Corruption/Missing
Data
• Make
corrections
in
the
Source
System
prior
to
export
• Automate
transformation
as
much
as
possible
Transform:
Compliance
Validate
• Validate
all
tools
• Validate
the
process
Rules
QA Approval
Rules
• Document
transformation
rules
QA
Approval
• QA
sign
‐
off
on
all
transformed
metadata
rules
Transform:
Key
Pitfalls
to
Avoid
Electronic
Rendition
d
Electronic
Signatures
• How
are
Rendition
Management
• Do
all
content
Metadata
• Will
all
signatures
manifested
in
the
current
files
have
renditions
for
controlled
attributes
exist
in
the
next
system?
system?
• Are
they
applied
to
renditions
on
viewing?
• Do
they
need
to
be
modified
for
• How
will
the
values
for
new
attributes
be
the
fly,
or
stored
in
the
storage
in
the
new
system?
Load:
Introduction
• Importing
to
SharePoint
requires
planning
for
how
and
where
Planning
you’ll
store
your
data
• Standard,
base
SharePoint
d h
l
Load
• Customized
SharePoint
solutions
• COTS
EDMS
SharePoint
Load
Load: Where is Data Loaded?
Other EDMS
Render
Solution
Other
EDMS
Components
SharePoint
Load
utilities
via
talk
the
to
API
EDMS
Solution
SharePoint
SharePoint
API
Load:
Understanding
Content
Requirements
Previous
Versions
• Determine
if
Native
Content
• Migrated
Renditions
• Understand
Permissions
• Document
previous
versions
are
required
in
the
content
may
look
different
than
content
created in the
the
rendition
management
solution
• Ensure your
permissions
must
be
set
by
the
API
during
import
the
compliance
SharePoint
EDMS
h b
created
in
the
new
system
• Metadata
gets
fused
into
d
• Ensure
your
migrated
PDFs
won’t
be
overwritten
–
h
h
import
• They
should
match
library
and
content
• Can
this
be
stored
in
an
archive?
document
properties
for
all
documents
they
have
signatures
embedded!
type
settings
Load:
Things
to
Consider
How are Renditions
Managed? • Unlike a traditional EDMS content Historic Electronic Signatures • If they’re on the PDF, you need to Are Documents
Keeping Their Version
Number?
• SharePoint doesn’t
allow the manual
Data Verification
• All good migration
tools verify data EDMS, content
objects in SharePoint
will always exist
independently • Will both the native
d PDF diti b
you need to
understand the
render solution • If they’re metadata
only, how will they
if t Eff ti
allow the manual
setting of a version
number via the API • To load a document
as v4.0, the import
t l t h k
tools verify data
against a
configuration prior to
load
• Ensure that: and PDF rendition be
loaded to the same
library?
• How are the native
and PDF rendition
l k d
manifest on Effective
copies?
tool must check a
document out and in
4 times to set the
version label to 4 • This will add to the
l d
• All required fields
are completed • All of the fields
match the target
data type linked? load time • Any list‐driven
Load:
Archiving
Options
Legacy
System
Database
File
Share
SharePoint
• Keep
system
running
• Limited
b
f
• Metadata
• Content
files
either
in
DB
fil
h
• Spreadsheet
of
metadata
• Content
Fil
• Simple
library
with
“text”
metadata
number
of
licenses
or
file
share
• Accessible
via
report
Files
metadata
• Content
files
are
stored
directly with
directly
with
metadata
Quality
Oriented
Migration
Phases
Plan
Development
Validate
Migrate
Overall
Project
Planning
Migration
Utilities
Export
Overall
Technical
Analysis
Create/Modify
Utilities
Based
on
Requirements
Transform
Requirements
q
Migration
Process
Data
Migration
Validation
Deliverables
Plan
Develop Validate
Migrate
Data Migration Plan Data Migration Test Protocol •Export •Transform •Load Data Migration Utilities •Load
•Post‐Load Verification
Migrated Production Data Data Migration Requirements Data Migration Summary Report
Key
Data
Migration
Validation
Deliverables
Data Migration
Data Migration
Data Migration Test
Data Migration
Data
Migration
Plan
• Outlines
the
approach
E l i
th
Data
Migration
Requirements
• Detailed
export
requirements
D t il d i
t
Data
Migration
Test
Protocol
• Protocol
Wrapper
• Export
Test
Script
Data
Migration
Summary
Report
• Documents
results
of
Data
Migration
• Explains
the
source
and
destination
systems
• Defines roles and
• Detailed
import
requirements
• Field
mapping
• Guides
d
l
t f
• Transformation
Verification
Script(s)
• Load
Verification
S i t
Migration
validation
testing
• Prerequisite
of
releasing
system
to production
• Defines
roles
and
responsibilities
development
any
custom
tools
of
• Provides
traceability
for
Data Migration
Script
• Error
Handling
Check
• Post
‐
Load
Processing
to
production
Data
Migration
Succeeding
in
Your
Migration
Plan
Prepare
Process
Prosper
Plan
Prepare
Process
Prosper
Questions
Joe
Lucadamo
