In recent times, there has been a rapid rise in the use of SharePoint (SP) and a number of enterprises are considering migration from PHP to SP. While there is of course huge amount of benefits associated with staying put with Open-Source PHP, SharePoint being a Microsoft supported platform comes high on security and other benefits as well. Weighing in on the pros and cons of both, there are migrations happening both ways – while some businesses are changing from SharePoint to PHP, other are going the Microsoft way.
Custom SharePoint development ensures that your enterprise’s collaboration efforts hit the roof while redundancies in processes are eliminated. And that often attracts businesses to migrate to SharePoint. The challenge lies in ensuring that SharePoint is appropriately implemented within the environment. It is true that the document management system can be conveniently installed as well as configured. However a number of organizations tend to make certain mistakes while migrating from PHP to SharePoint.
Let us have a look at 10 mistakes which should be avoided.
1. Choosing the basic installation for SharePoint: During installation of SP many organizations are into the habit of going for the basic install option. Although the basic version can be installed with simply a few clicks of the mouse, the advanced option is always better, so far as enterprises are concerned. It is advisable to choose the advanced option if you are not interested in installing everything on a single server or want to utilize complete SQL server, either existing or new.
2. Ignoring Fault tolerance: While migrating from PHP to SharePoint, a number of enterprises commit the mistake of considering that load balancing or greatly obtainable environments are meant for performance. The truth is that most of the times, fault tolerance is a greater priority and the actual reason behind leveraging load balancing, or any other highly available solution such as RAID. The configuration of an environment with high availability is not feasible with the basic installation.
3. Inappropriate utilization of permissions and service accounts: Like a lot of other server-oriented tools, SP has to interact with the server on which it is installed as well as the services surrounding it. As a result, service accounts are required, which are in fact, special identities used for communication with crawl content, SQL server, add index information across the file system, amongst various other functions. Many organizations make the mistake of going for generic server accounts, which is not at all recommended. In place of this, distinct domain accounts are required for every primary SP service.
4. Iterating by means of SPList Items: Developers have access to SPList object and are capable of using the same either from the existing SPContext or through creation of a SPList object to gain access to a list identified through its name. Although the used code is good for local environments, it leads to performance problems in case of custom SharePoint implementations.
5. Excessive data request from content database: With the help of the SPList object, data can be conveniently accessed from the Content Database. The problem is that every time this action is taken, it leads to requesting all the list items. Using SPQuery object, the data that is really needed can be queried. SPQuery facilitates putting a limitation on the number of returned items and columns as well as raising query for particular items through utilization of Collaborative Markup Language.
6. Memory leaks through SPWeb and SPSite: For those considering migration from PHP to SharePoint, it should be remembered that SharePoint makes use of COM components for certain core features. So far as COM Objects are concerned, memory management can be an issue. SharePoint installations often do not dispose SPWeb and SPSite objects and hence the ASP.NET Worker Process ends up leaking memory. So, it is advisable to monitor the memory usage to identify memory leaks.
7. Use of Index Columns for Performance Enhancement: Index Columns can offer speedy access to SharePoint Lists but there are certain limitations. With respect to every defined index, the index value is stored by SP for each list item in a distinct table. Queries utilize the first index column while additional index columns are not utilized for speeding up database access.
8. Using SP for transactional processing of great volume: It is a good thing that SharePoint does not bound you to the content database, but you should not use it for high volumes of transactional processing. A single table stores every data element. Implementation of database indices takes place through use of a second table which is then attached with the main table. Simultaneous access to different lists becomes an issue since the data belongs to the same table.
9. Inappropriate drive space allocation: The SharePoint installation procedure puts location of custom solutions, indexes, software and logs across the primary system drive, which is most of the times, the C drive. However, in a number of organizations, the C drive is partitioned into smaller components for the OS files. Consequently, space can rapidly run out.
10. Not focusing on disaster recovery situations: While engaging in migration from PHP to SharePoint, many organizations tend to disregard the disaster recovery continuity plans. SP is more intricate than other database driven portals. Hence, the architecture should be understood and accordingly plans should be made for reconstituting the environment.
These are the mistakes that are committed most often by organizations while migration from PHP to SharePoint. Avoiding these mistakes will save time and reduce the possibility of future issues.
We provide SharePoint webparts development services. If you would like to talk to one of our certified SharePoint developers, please get in touch with us at Mindfire Solutions.
Let us have a look at 10 mistakes which should be avoided.
1. Choosing the basic installation for SharePoint: During installation of SP many organizations are into the habit of going for the basic install option. Although the basic version can be installed with simply a few clicks of the mouse, the advanced option is always better, so far as enterprises are concerned. It is advisable to choose the advanced option if you are not interested in installing everything on a single server or want to utilize complete SQL server, either existing or new.
2. Ignoring Fault tolerance: While migrating from PHP to SharePoint, a number of enterprises commit the mistake of considering that load balancing or greatly obtainable environments are meant for performance. The truth is that most of the times, fault tolerance is a greater priority and the actual reason behind leveraging load balancing, or any other highly available solution such as RAID. The configuration of an environment with high availability is not feasible with the basic installation.
3. Inappropriate utilization of permissions and service accounts: Like a lot of other server-oriented tools, SP has to interact with the server on which it is installed as well as the services surrounding it. As a result, service accounts are required, which are in fact, special identities used for communication with crawl content, SQL server, add index information across the file system, amongst various other functions. Many organizations make the mistake of going for generic server accounts, which is not at all recommended. In place of this, distinct domain accounts are required for every primary SP service.
4. Iterating by means of SPList Items: Developers have access to SPList object and are capable of using the same either from the existing SPContext or through creation of a SPList object to gain access to a list identified through its name. Although the used code is good for local environments, it leads to performance problems in case of custom SharePoint implementations.
5. Excessive data request from content database: With the help of the SPList object, data can be conveniently accessed from the Content Database. The problem is that every time this action is taken, it leads to requesting all the list items. Using SPQuery object, the data that is really needed can be queried. SPQuery facilitates putting a limitation on the number of returned items and columns as well as raising query for particular items through utilization of Collaborative Markup Language.
6. Memory leaks through SPWeb and SPSite: For those considering migration from PHP to SharePoint, it should be remembered that SharePoint makes use of COM components for certain core features. So far as COM Objects are concerned, memory management can be an issue. SharePoint installations often do not dispose SPWeb and SPSite objects and hence the ASP.NET Worker Process ends up leaking memory. So, it is advisable to monitor the memory usage to identify memory leaks.
7. Use of Index Columns for Performance Enhancement: Index Columns can offer speedy access to SharePoint Lists but there are certain limitations. With respect to every defined index, the index value is stored by SP for each list item in a distinct table. Queries utilize the first index column while additional index columns are not utilized for speeding up database access.
8. Using SP for transactional processing of great volume: It is a good thing that SharePoint does not bound you to the content database, but you should not use it for high volumes of transactional processing. A single table stores every data element. Implementation of database indices takes place through use of a second table which is then attached with the main table. Simultaneous access to different lists becomes an issue since the data belongs to the same table.
9. Inappropriate drive space allocation: The SharePoint installation procedure puts location of custom solutions, indexes, software and logs across the primary system drive, which is most of the times, the C drive. However, in a number of organizations, the C drive is partitioned into smaller components for the OS files. Consequently, space can rapidly run out.
10. Not focusing on disaster recovery situations: While engaging in migration from PHP to SharePoint, many organizations tend to disregard the disaster recovery continuity plans. SP is more intricate than other database driven portals. Hence, the architecture should be understood and accordingly plans should be made for reconstituting the environment.
These are the mistakes that are committed most often by organizations while migration from PHP to SharePoint. Avoiding these mistakes will save time and reduce the possibility of future issues.
We provide SharePoint webparts development services. If you would like to talk to one of our certified SharePoint developers, please get in touch with us at Mindfire Solutions.
No comments:
Post a Comment