Forum

[MaDurga]

Dear all, can anyone point me on the right direction on migrating website from their existing CMS to Crownpeak.

[CP_Product]

Hi Somnath -

Thanks for this question! 

I would recommend taking a look at this guide for a better understanding of our architecture. It's a good place to start to understand the decoupled structure you'll be transitioning to.

https://community.crownpeak.com/t5/DXM-Template-Development/DXM-Architecture-Overview/ta-p/1184

@ArcadioP , is this something the services team can help answer?

Also, @MarcusEdwards , has this come up in training?

Best,

Denise

[DavidGreenberg]

Hello Somnath,

a) The primary language used within the cms is C# for template code. As such I would recommend you hire either a .net member to translate your previous templates into Crownpeak Templates. You could also hire one of our partners or our own service team.

b) I would recommend getting the site architecture as you will need to recreate the folders within the cms to match the current design. However I do not believe you will need the previous cms architecture.

c) I would recommend the same as Denise: https://community.crownpeak.com/t5/DXM-Template-Development/DXM-Architecture-Overview/ta-p/1184

d) You should be able to redesign the site using their architecture and files. Essentially if you can retrieve a copy of the site from the server itself, i.e. .js, .html, .aspx, .css, ect,.

Thank You,
David

[ArcadioP]

Hi Somnath,

For every new CMS Implementation that we work on, we start by doing an in-depth review of the site that will be migrated (or newly created) in Crownpeak so we can completely understand the different items that need to be implemented/configured. Below you can find a summary of these areas:

1. Hosting: Review DNS configuration and monitoring requirements.
2. User Experience and Front End: References and links to the customer-provided Site Map, Wireframes, Comps, and visual components and front-end HTML, CSS, and JavaScript (existing or new designs).
3. Functional Requirements: This is a detailed page-type level description of functionality for the published site.
4. Templates and Widgets Design: Describes the templates and fields for input, the widgets and components needed to support the site functional requirements and the technical design needed to support the functionality, including all coding required
5. Integrations Design: Describes how integrations to third-party sites and functionality will be achieved
6. Folder Architecture: This defines the structure of the CMS implementation.  The recommended architecture enables all users to access to their content and enables administrators to control access as needed.
7. Crowpeak Components: Define integrations with the CMS and other Crownpeak components including WCO, Search, Translation Model Framework (TMF), etc.
8. Models: Details of the end user configuration.
9. Groups/Roles: This defines the types of users that are in your system (Authors, Editors, Administrators, etc.)
10. Workflow: This defines the path your documents take from creation to publishing on your live site is defined.
11. Users: With the Groups and Workflow defined, describes the users of the CMS and what group(s) they will belong to.

Please let us know if you have additional questions.

- Arcadio

[MaDurga]

@ArcadioP @DavidGreenberg @CP_Product 

I cannot thank you enough for your valuable guidance. These information is going to be of great help for me and my team.

My dev team has .net developers, java developers and a few React guys. The old site is presently on the Scorpion CMS and we want to migrate the content from them to Crownpeak. We are enthusiastic to experience the heavy lift and shift job ourselves. Please could you help us identify the tools to migrate the content from Scoprion to Crownpeak CMS?

Also, can you help to identify the approach to migrate 1m users from Scoprion CMS to AWS Cognito and the approach to integrate AWS Cognito with Crownpeak?

 look forward to hearing from you guys soon.

[DavidGreenberg]

Hello Somnath,

I believe this will provide some more details on moving your site to the Crownpeak CMS.

https://community.crownpeak.com/t5/DXM-Developer-Knowledge-Base/CMS-and-HTML-Requirements-and-Recomm...

Thank You,
David

[MaDurga]

@DavidGreenberg, Thank you for sharing the document link. It is very useful. 

1. If the CMS web pages have a lot of Angular or React code ( i.e application JavaScript files) then how do we maintain it in single repository as application test and CM repository  environment seamlessly ( I hope we have to use CP API)
2. Does every api has two way like UploadAsset() and GetAsset().
3. And if we choose deployment within CMS site then does this mean my CI/CD pipe line would integrate with CP API in order to publish.

[MarcusEdwards]

I always tell people at the start of implementation to design the solution they need independent of Crownpeak -- this is one of the key benefits you get from our decoupled architecture. The principle should be: bring Crownpeak to your application build; not build your application on Crownpeak.

Once you have the application design, identify the elements of the design (front-end and back-end) that require content management or could be delivered by Crownpeak DXM dynamic services like Search G2 and WCO. This will give you your first pass on identifying templates. 

A critical question you will need to resolve is what your content delivery hosting looks like (technology stack and configuration), who will be providing it, and how you access it.

If you are using Crownpeak hosting, you should know that in order to maintain our security certifications, we do not provide any access to the hosts directly -- no remote desktop, no SSH shell and the only SFTP connections that will be accepted need to come from the DXM servers. This severely restricts your deployment options to one: you will need to deploy your application code as well as any content from the CMS.

Even if you are using Crownpeak hosting for production, I would strongly recommend setting up a development environment that you provide and have full access to as this will greatly improve your ability to debug problems as you would have direct access to the host(s).

Crownpeak does have the Access API that can be used in your build pipeline to create and update assets in the CMS and to trigger publishing by updating workflow states. In your case, this sounds like it could only be appropriate to do this integration for release builds rather than CI builds.

[MarcusEdwards]

On the subject of "the approach to migrate 1m users from Scorpion CMS to AWS Cognito": neither of these are Crownpeak products so this isn't the forum to ask about this. 

On the subject of "integrate AWS Cognito with Crownpeak": you need to recall the Crownpeak decoupled architecture and clarify whether you need to integrate AWS Cognito with the DXM repository, which doesn't look like the correct thing to do, or whether you are asking about integrating AWS Cognito with a something on the content delivery side of things -- a web application that you are publishing part or all of from the DXM repository for example. In this case, again, there is nothing Crownpeak-specific about this as it all happens on the content delivery side: see User Pool authentication flow.

[MaDurga]

Thank you so much Marcus for the detailed explanation and also for the document link. Your guidance on CMS Migration is very helpful and certainly you have put me on the right direction. Have a great day ahead!