Before you change the portal
An investor portal migration starts with deciding what must remain reliable when investors move to a new destination: their access, their documents, their reporting history, and the people responsible for helping them.
This checklist is for private capital teams moving from an existing portal or upgrading a process built around shared folders, emailed PDFs, and spreadsheets. Use it to prepare the work, compare implementation proposals, and agree on what must be verified before investors are invited.
The same questions apply when evaluating Graviron. Confirm the scope, supported formats, historical coverage, provider responsibilities, and implementation assistance for your particular situation. This is a planning guide, not a promise of automated imports, a fixed migration timeline, or compatibility with every existing system.
1. Define the change and who owns it
Write down which funds, products, accounts, investor groups, and reporting periods are included. Separate the first launch from later phases. A limited first release can be useful, provided its boundaries are clear to the team and to affected investors.
Name the people responsible for source records, document approval, access decisions, investor communications, and the final decision to switch. Include the fund administrator and other appointed providers where their responsibilities are involved.
Agree on the first reporting event the replacement must support. Choose a transition window that leaves room for review and assistance rather than assuming an important reporting deadline is also a convenient launch date.
2. Inventory documents before moving them
Create a document inventory that records the file name, document type, fund or product, relevant account or investor, reporting period, version, approval status, and intended audience. Identify the source location and the person who can resolve a discrepancy.
Look for missing periods, duplicate files, inconsistent names, unreadable PDFs, and drafts mixed with final materials. Decide which version is authoritative before migration. Copying every folder can carry old confusion into a new interface.
Ask the prospective provider which file formats and metadata it can accept, how documents will be associated with the correct records, and what happens to items that cannot be mapped. Use synthetic or appropriately authorized examples for evaluation.
3. Map access to relationships, not just email addresses
An email list does not fully describe who should see what. The same person may represent more than one entity, have several accounts, or be entitled to some documents but not others.
Prepare an access map connecting each authorized person to the relevant entity, account, fund or product, and document audience. Record who approves each relationship. Flag former contacts, shared inboxes, representatives, and delegated access for review rather than inheriting every old permission.
Ask the provider to demonstrate both sides of access: an authorized person can find the right material, and someone outside that audience cannot. Verify representative cases before invitations are sent. The firm retains responsibility for entitlement decisions.
4. Preserve the meaning of reporting history
Decide how far back history needs to remain available and where investors will find it. Some material may move into the new portal; other records may remain in an agreed archive. Make the distinction explicit.
For each historical report, preserve the account, period, issue date, and revision context that make it understandable. Confirm whether the proposed migration covers final documents, structured data, or both. These are different scopes.
Compare a sample of historical and current materials against approved source records. A change in presentation should not silently change an amount, date, ownership relationship, or reporting definition. Refer discrepancies to the responsible team or professional provider before release.
5. Test one complete investor experience
Before a broad rollout, walk through a representative journey using approved test accounts and sample information: receive access, sign in, locate the correct account, open the current report, find an earlier period, and identify where to ask for help.
Include a person with multiple accounts and two people with different document entitlements where those situations apply. Check common phone and desktop layouts, downloads, document labels, and links referenced in your communications.
Record the result, the owner of each issue, and what must be resolved before launch. A successful file upload is only one part of a successful investor experience.
6. Plan communications and the changeover
Tell investors what is changing, when to use the new destination, what history will be available, and how to get help. Explain any required sign-in steps in language that has been checked against the actual experience.
Decide how long the old destination remains available, whether it becomes read-only, and how information arriving during the transition is handled. Keep one agreed source of current investor-facing materials so parallel systems do not create competing versions.
Before changing access, agree on the conditions for postponing the transition and the fallback if a material problem appears. Confirm export availability, contractual notice requirements, and archive access with the existing provider before retiring the old service.
7. Close the transition with evidence
Compare the agreed inventory with what is available in the new destination or retained archive. Record unresolved exceptions and their owners. Confirm that the responsible people have accepted the document set, access mapping, historical coverage, and support arrangements.
Review the first reporting cycle after launch. Can investors find the approved information? Are access questions reaching the right person? Has the team reduced repeated manual work? Use those observations to address remaining gaps before expanding the scope.
Retire the old portal only after the firm and its relevant providers confirm the agreed retention, access, and transition requirements have been met.
The checklist to take into your next conversation
Bring six things: a defined first-release scope; a document inventory; an approved access map; a decision on historical coverage; a tested investor journey; and an agreed changeover and fallback plan.
Ask each vendor to distinguish what is supported today, what requires configuration or professional services, what remains your team’s responsibility, and what is unavailable. Get the proposed migration scope, exclusions, and costs in writing.
For broader selection criteria, read Graviron’s investor reporting software buyer’s guide. To understand the platform’s wider role, explore Graviron’s private capital infrastructure.
Where Graviron fits
Graviron’s focus is institutional software infrastructure for private capital reporting, investor experience, documents, and customer-owned workflows. A portal transition is an opportunity to consider how those responsibilities and records connect across the investor relationship.
When considering Graviron, start with the materials, access needs, and historical continuity your organization must preserve. Confirm the implementation scope against those requirements before committing to a transition. The firm and its appointed providers retain their professional responsibilities and approval authority.
Graviron provides software infrastructure, including fund administration software; responsibility for fund administration remains with the fund manager and its appointed providers. Graviron does not provide investment advice, custody, brokerage, securities placement, fund management, legal services, or tax advice. Nothing on this site is an offer to sell or a solicitation to buy securities.