Skip to content

Migrating from AyaNova 7 to AyaNova 8

This help page outlines the setup tasks that will need to be done after migration from a business administration point of view.

For the installation guide for AyaNova 8 see the AyaNova 8 server installation guide.

For a technical guide to migration process see the Operations migrate guide.

For a guide to the feature changes from AyaNova 7 see the Changes from AyaNova 7 guide.

Migrating from AyaNova versions older than 7.6

To migrate to AyaNova 8 from versions of AyaNova older than AyaNova 7.6 the process is to upgrade in two steps: Upgrade to AyaNova 7.6 first then migrate the data to AyaNova 8.

Contact our support department for the resources and instructions required.

Plan the migration

The migration should be planned and tested in advance and involve all staff who use AyaNova to ensure the minimum possible disruption to the business.

Plan for one or more test migrations

AyaNova 8 is different from prior versions and we recommend doing one or more test migrations before scheduling with your staff to do the final switch-over.

A test migration will be necessary to determine how long the process will take to help with planning the final migration and business switch over to AyaNova 8 to ensure the minimum possible down-time.

Plan on taking ample time to go through the migrated data in AyaNova 8 to confirm everything expected has been migrated properly.

Plan for time to familiarize staff

Take the time to familiarize yourself and your staff with the changes in the new version of AyaNova so that everyone is comfortable with what to expect and ready to start work as soon as the final migration is completed.

Be sure to have all staff carefully test all business processes they require in AyaNova with a test migration before final migration so that everyone is up to speed and able to continue working without interruption after the final migration.

AyaNova 8 database will be erased

The migration process will erase all data including attached files in the AyaNova 8 database as the first step.

There is no ability to synchronize or partially migrate only recent changes from v7; the migrate process entirely replaces the V8 data each time it's run.

What is migrated and where

All objects

All migrated business objects can be tagged to easily identify them as having been migrated down the road.

By default migration will tag all migrated objects with "v8-migrate" or you can clear this field and leave it blank if you do not wish to have all the migrated items tagged.

This tag is provided so there is a record of which items were migrated and which were created after migration however there is no technical requirement for this tag; it's for informational and troubleshooting purposes only.

Most objects

Most object will retain their name and will be migrated directly with the following exceptions:

Global Wiki

v8 does not have a Global Wiki page (the Wiki page formerly accessible from the opening screen in AyaNova 7), the migration will move the Wiki and any embedded files to a User account created just to contain it's Wiki and attached files named "zV8Migrate GLOBAL_WIKI_REPOSITORY".

Region Wiki

v8 does not have Regions, all functionality previously in Regions will be split out into several new and changed objects. The Region Wiki if found will be migrated to a User account created just to hold the Wiki and files named "zV8Migrate REGION_WIKI_REPOSITORY_region name"

Security groups

  • Security groups have been replaced by Roles.
  • No v7 security group information or settings are migrated into v8.
  • v7 migrated Users will automatically be set to No Role in order to protect information security; the business administrator will need to set each user to the most appropriate new roles after migrated is completed.

For details see the Authorization roles guide for more information.

Clients

  • v7 Clients have been renamed to "Customers"

Parts

  • In v7 Parts had Part number and Part Name fields. Part Number was always intended as the primary identifier for a part however in v8 we've changed Parts to use the more consistent Part Name as the primary identifier. Users should use the Part Name field in v8 as the primary and sole identifier for a Part wherever possible. This field like all v8 name fields has no practical length limit and should be the main field used to identify parts both internally and externally.

In order to accomodate this change, the V8 migration utility offers two ways to migrate the existing part fields as an optional choice before migration:

  1. Consolidate the v7 Part number and Part name fields into the single v8 Part Name field {partnumber} {partname} (default and recommended for most)
  2. Import the v7 Part number field into the v8 Part name field and the v7 Part's 'Name' field into the v8 Part's 'Description' field

Unit Models

  • In v8 Unit Models no longer have the "Model Number" field. The "Name" field is now the primary identifier. Migrated v7 Unit Models will have their Model Number and Name fields combined into the single v8 Name field.

Schedule markers

Schedule markers are now split into two separate types of objects in v8 corresponding to v7 Schedule markers with a "follow up" object link and those that do not. V8 migrate will migrate the Schedule marker to the appropriate new object type as follows:

Reviews

Schedule markers that are a Follow up type (tied to a particular object) are migrated to the new "Review" type object in AyaNova 8.

Reviews do not have colors or Start or Stop dates so those properties are not directly migrated however the dates do influence some other properties: The dates are migrated specially depending on if the v7 schedule marker Stop date has passed or not: If the v7 stop date has passed then the v8 Review record has it's "Review" date set to the v7 Start date and it's "Completed" date set to the v7 Stop date. If the v7 stop date has NOT passed then the v8 "Completed" date is left empty and the v8 "Review" date is set to the v7 Start date.

Reviews do not have a Completed checkbox to migrate as it has been superseded by a Completed date, however Reviews are tagged with a Completed Tag if they were completed in v7 in order to preserve that historical information.

Reminders

Schedule markers that do not have a follow up link are migrated to v8 as "Reminder" type objects.

All properties are migrated with the exception of the Completed checkbox: Reminders do not have a Completed checkbox so that property is not migrated however they are tagged with a Completed Tag to preserve that information.

Localized Text / Translation

  • In V8 Localized text has been renamed to "Translation".
  • V7 Localized text will only be migrated if it has been customized. Any customized Locales will be migrated to the best guess of source language into AyaNova 8. It tries to make a best guess as to which language each user was using but if it can't tell it defaults to the English based translation. You can adjust this after migrate for the users or they can set it themselves and you can delete any un-needed translations.

IMPORTANT NOTE ABOUT MIGRATED TRANSLATIONS V8Migrate will migrate customized translations from v7 and set the migrated Users to that same translation, however, we strongly recommend that you do not actually use the migrated translation once familiar with where everything you need appears in v8 but rather replicate any custom translation changes required in one of the stock V8 translations to avoid confusion as several objects have been renamed for clarity. For example if your default translation is English and you have renamed an object or a phrase in v7, make a duplicate copy of the 'EN' default stock translation in V8 and edit the object or phrase in that translation and set it for your Users rather than continuing to use the migrated translation.

This will avoid issues with documentation and some areas of the UI being in conflict with other areas and ensure the new, clearer translations are displayed.

Custom fields

Custom fields are migrated with a slight change: the custom field numbering in AyaNova 8 starts at "1" instead of "0" as it did in AyaNova 7.

In other words the AyaNova 7 field Custom0 will be migrated to the AyaNova 8 field Custom1, AyaNova 7's Custom1 would be AyaNova 8 Custom2 etc.

Wiki embedded files

  • In V8 Wiki embedded files are now Attachments and are separate from the Wiki page.
  • In v7 only a limited set of objects could have Wiki pages and embedded files, now, all business objects support Attachments

Tags

Tags are a new feature for AyaNova 8 that replace and improve upon several different categorization features in v7.

The following objects from v7 will be migrated as tags in v8:

  • User certification
  • User skill
  • Client group
  • Dispatch zone
  • Part category
  • Regions
  • Scheduleable user group
  • Unit service type
  • Unit model category
  • Vendor type
  • Work order category
  • Work order item type

Objects migrated to v8 will automatically be tagged with the corresponding tag that replaces the above feature.

Wiki pages

Wiki pages have change substantially in v8 based on user feedback.

  • In v7 only a limited set of objects could have Wiki pages and embedded files, now, all business objects support Wiki pages
  • The migrate process will by necessity need to discard some unsupported formatting elements from the v7 format wiki pages.
  • Things that will be lost in the migration process are:
  • Colors
  • Font sizes
  • Font faces (i.e. "Arial", "Courier" etc)
  • Text alignment (left, center, right)
  • internal AyaNova links to objects (for example linking directly to a Client record inside a wiki page)
  • Things that will be kept:
  • All entered text
  • Lists
  • Bolded text
  • Underlined text
  • Italicized text
  • Images
  • External URL links
  • Wiki embedded files (will be migrated to new attachments feature)

Users

Users are migrated directly with the following exceptions:

  • Security group, now Role, see above
  • Login credentials and password are not migrated and will need to be set
  • Active status is set to false on all migrated users except the Adminstrator account
  • Administrator account password is not migrated, instead the new v8 SuperUser account replaces it and defaults to login "superuser" and password "l3tm3in"

Manager / SuperUser User account changes

The AyaNova 8 SuperUser User account is different from the v7 Manager User account as it can only be used for server administration tasks and creating / editing other Users.

Unlike the v7 "Manager" User account the v8 "SuperUser" special account is not able to view any business related objects so if you login as SuperUser you will not see any business objects such as Customers (clients) or Work orders for example.

The equivalent Role to have full access to all busines objects in AyaNova 8 similar to the Manager account in v7 would be to login as a User who has been given the Busines administration role.

Service bank

The service bank feature has not been ported to AyaNova 8 as it does not appear to be widely used and would need extensive re-working. We could be wrong about this and if the Service Bank feature is important to you please let us know and how you would like to see it implemented as a feature. If there is demand for it we can work it back into AyaNova 8 as a feature based on your feedback. No data is migrated from the v7 Service Bank to v8.

Inventory

To ensure the inventory balances match, all parts are initially migrated to v8 with one billion in stock quantity. Then all inventory related objects are migrated such as Purchase Orders, Inventory adjustments and Service Work orders. Finally at the end of migration inventory transactions are made to the v8 inventory levels to bring the quantities on hand into balance with the v7 quantity on hand for each part. In AyaNova 8 inventory is consumed the moment a Part is saved on a work order which differs from v7 where inventory is consumed when a Part is set to Used in service on a work order.

Work order item parts not "Used in service"

v8 work order item part affects inventory immediately when entered and saved but in v7 inventory is not affected until "Used in service" is checkmarked. For this reason, v7 work orders with work order item parts not checkmarked Used in service will have those quantities migrated to the "Suggested quantity" field instead of the Quantity field. This is to ensure that inventory remains in balance after migration.

In v8 Users will need to either use the "Realize suggested part quantities" command in the work order to automatically copy the suggested amounts to the Quantity field in all work order item part records for that work order or manually enter each one in the quantity field as appropriate.

Inventory adjustments

Inventory and Serial numbers work differently in v8; Inventory adjustments can not be migrated with their original entry dates as the new v8 inventory "blockchain" system does not allow entries out of order so they are migrated as Inventory Transactions in v8 and the description of the transaction is named in this pattern: v7Adjustment {v7 inventory adjustment ID number} {v7 adjustment "reason" field} {v7 adjustment "Date Adjusted"} For example "v7Adjustment 45 Store stock opening inventory adjustment on 2005-11-27 10:50:53 AM".

Serial numbers

Serial numbers also differ in v8 as they are now separated from inventory completely. All serials are migrated into the new v8 serial number system and can be viewed and verified on the Part list "Available serial numbers" column or from within a Part form by selecting the "Available serial numbers" menu item to open the edit form for editing Serial numbers for that part.

Closed / Service Completed Work orders

V8 does not have a Service Completed or Closed checkbox. Instead those features are replaced by the new status system in v8.

During migration two locking type Work order status are created automatically "Closed (v7)" and "Service Completed (v7)". The closed status is a locked type to prevent editing and also a Completed type to signal that the work order is completed and no further edits are anticipated which replaces the Closed checkbox in v7.

The service completed status is also a locked type to prevent editing but is not a Completed type indicating there may be further edits to the work order and this replaces the Service Completed checkbox from v7.

When a v7 Work order is migrated, if it is set to Closed then it will have it's status automatically set in v8 to "Closed (v7)" which ensures it is locked to prevent editing and v8 will recognize it as a Completed work order as Closed v7 is a Completed type status.

If a work order in v7 has it's Service Completed checkbox checked but is not Closed then it will have it's status set to "Service Completed (v7)" which is ensures it is locked to prevent editing.

The original status in v7 is preserved in v8 as v8 status are now a collection rather than a single item so clicking on status will show the original v7 status.

Report templates

AyaNova 7.x report templates are not compatible in any way with AyaNova 8 report templates and can not be migrated automatically.

The most common reason people have modified AyaNova 7 report templates was to add their logo, that is now handled automatically for you in AyaNova 8 so there may not be a need to customize reports.

Report templates in AyaNova can be customized and new ones created using the built in report template editor.

We recommend looking through the reports you might use in your business and make or plan for any changes required if the stock report templates don't meet your needs as they are.

We suggest making a duplicate copy of any stock report templates you want to modify first and then working with the duplicate so that you always have the original for reference.

If you prefer to have report templates modified or created for you, we may be able to provide that service for a fee, contact AyaNova support for details.

What you need to do after migration

View the migration log

A copy of the migration log is automatically sent in AyaNova 8 in a Memo to the SuperUser account and is a mirror copy of the migration log displayed during migration.

This log may contain important instructions and indications of any objects that could not be migrated or will need attention.

Be sure to check this log carefully before proceeding and take any actions recommended.

Check your data

Ensure that your data has migrated by comparing and confirming v7 to v8 objects in both AyaNova 7 and AyaNova 8.
You should keep a copy of AyaNova 7 available for some time after migration for reference purposes in case any questions arise.

Setup users

Users are migrated to inactive accounts with no authorization Roles, password or login name set.

Note: Inactive users do not display in the v8 schedule - in v8 the schedule does not show scheduled user records for inactive users so initially you will not see scheduled items show in the schedule until Users are set back to Active=true.

All active users will need to have some settings made:

  • Role - you will need to select one or more Authorization Roles to grant the User access to AyaNova.
  • Login and Password - These are not migratable and need to be set for the user to log in, they can change their login and password themselves once they log in.
  • Translation - The migration process will make a guess as to the most appropriate translation but you may need to adjust this setting
  • Active - users are migrated as Inactive and must be set to Active

Once Users are able to login they will need to subscribe to any Notifications they require. The V8 Notification system is simplified from v7 and easier to set up but it can't be migrated as they are very different systems.

Assign a User the Operations - limited role

It is important to assign one or more regular (non I.T. department) AyaNova Users the Operations - limited role so that the automatic backup can be monitored and when necessary the various AyaNova server diagnostics logs and other information can be viewed as a second set of eyes on critical AyaNova server operations.

This is particularly helpful when there is an outside I.T. person responsible for AyaNova as the Operations - limited role user can use their role to provide information to the outside I.T. person to help determine if they need to take care of something related to the smooth operations of the AyaNova server.

Customize Translations

If you had previously been using a customized Locale in v7 read the important note regarding this in the section above. We recommend not using the migrated translation but rather replicating any changes needed in a copy of a v8 stock language translation and setting User's to that translation rather than the one the v8Migrate has created.

Re-create report templates

See above: Report template migration.

RI / WBI Client access settings

The V8Migrate utility is not able to access settings in the optional add-on's RI and WBI and so is not able to automatically migrate their settings to AyaNova 8. Instead it will automatically choose safe defaults for those settings and lock out Customer access.

In v7 you would make those settings within the interface provided by those optional add-on's, in AyaNova 8 all those settings can be found in the Global Settings form in the Customer Access section and will need to be set manually.

Enable Backup

AyaNova 8 has a built in backup system that will back up to the local drive automatically. It is disabled by default and must be enabled to work.