Skip to main content

We're currently in the process of transitioning from APPS10 to IFS Cloud and are facing a significant challenge with migrating document attachments.

In our APPS10 environment, we used a shared repository for storing documents. However, with the shift to IFS Cloud, we've encountered an issue as shared repositories are not supported in the cloud environment. While we have set up a database repository in IFS Cloud for new document attachments, which is working fine, we’re blocked when it comes to migrating the existing documents from APPS10.

We need to ensure that all our existing document attachments in APPS10 can be brought over to IFS Cloud and remain accessible within the application.

I would greatly appreciate any insights or best practices on how to migrate these documents from a shared repository in APPS10 to a database repository in IFS Cloud. Has anyone else faced a similar issue, and if so, how did you resolve it?

Hi @ZOKAAMEER,

Please note that shared and FTP repositories are not supported in IFS Managed Cloud. The available options are:

  1. Database
  2. Azure File Storage

When migrating documents, you have a couple of options to consider:

  1. You can use the IFS Cloud file migration tool to migrate your documents from the shared repository directly to Azure File Storage. A step-by-step guide is available in the technical documentation: Cloud File Storage Migration Tool.

  2. Alternatively, you can migrate your shared repository documents to the database in your APPS10 installation using the ‘Change Document Repository’ functionality in APPS10 (pre-upgrade), and then upgrade from APP10 to the cloud.

We highly recommend migrating documents directly to Azure File Storage (Option 1) instead of the database, due to database size limitations (and associated costs) in the cloud.

Thanks!

Deshan


Hi Deshan,

Thank you for your quick and informative response. We appreciate the guidance on the available migration options.

As you pointed out, the Cloud File Storage Migration Tool is primarily designed to facilitate the migration of documents from a database repository to File Storage. However, our challenge is a bit different and significantly more complex.

We are tasked with migrating over 1.6 million files from a shared repository in our current APPS10 environment to IFS Cloud. To perform the Tech Doc mentions about a text file, and we need to add the details of each document to the text file, these files are stored in a shared file repo, and our primary concern is how to accurately and efficiently gather all the necessary metadata for each document. This metadata includes document number, class, revision, file name and path

A significant portion of our documents are named using result keys, which complicates matters further, as these filenames do not contain the metadata required for the migration. 

Given the scale of our migration and the complexity of the file structure (which includes multiple subdirectories), The process of extracting this information seems to be the most critical and challenging part of our migration effort.

Could you please advise on any tools, scripts, or methodologies that might help streamline this process? Additionally, if there are any best practices or considerations we should keep in mind when dealing with such a large-scale file migration, we would greatly appreciate your insights.

Thank you once again for your support and guidance as we navigate this complex migration.

Best regards,  
Azhar


Hi @ZOKAAMEER 

Can you elaborate a bit more on the file naming on shared repo? What do you mean by result key? Can you give an example of each variation you have?

In IFS Document Management, we name the files saved in such repositories in a unique key combination, this is called as the repository file name
format: DOC_CLASS - DOC_NO - DOC_SHEET - DOC_TYPE. docx

Does the above match your file naming? Or is there a different kind of name handling?


Thanks @deshan.ekanayake 

A small correction: the default naming scheme for the repository file name is DOC_CLASS-DOC_NO-DOC_SHEET-DOC_REV-FILE_NO. EXTENSION

That is, there are no spaces between the keys, document type (ORIGINAL or VIEW, in most cases) is not part of it, and the file number is there as well.

When in doubt though, check the file_name column in edm_file_tab. That's what we use when accessing files on FTP, Shared and File Storage repositories.

@ZOKAAMEER

Creating that text file is not hard, it can be done by any SQL tool and all the information you need is there in the table edm_file_tab.

 


Yes @Mathias Dahl @deshan.ekanayake 

From the below query I was able to get values in a correct way 
and i was able to a sample file migration too thanks for the replies 

SELECT 
    REPLACE(doc_class, ',', '\,') || ',' || 
    REPLACE(doc_no, ',', '\,') || ',' || 
    REPLACE(doc_sheet, ',', '\,') || ',' || 
    REPLACE(doc_rev, ',', '\,') || ',' || 
    REPLACE(doc_type, ',', '\,') || ',' || 
    REPLACE(file_no, ',', '\,') || ',' || 
    REPLACE(file_name, ',', '\,') || ',' || 
    REPLACE(user_file_name, ',', '\,') || ',' || 
    REPLACE(path, ',', '\,') AS combined_values
FROM 
    edm_file_tab


@ZOKAAMEER 

Thanks for replying back, and sharing that SQL.


Reply